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

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

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

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,

Re: [go-nuts] All goroutines hung in futex / sleep

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

Re: [go-nuts] Float multiplication bug?

finished. Steve, this may help explain. https://play.golang.org/p/tcy1QFZb-Fp On Thu, Feb 22, 2018 at 5:35 PM, Michael Jones wrote: > https://play.golang.org/p/0XRLg6-6uPk > > On Thu, Feb 22, 2018 at 1:09 PM, andrey mirtchovski > wrote: > >> in

Re: [go-nuts] All goroutines hung in futex / sleep

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 "interesting" stuff

[go-nuts] All goroutines hung in futex / sleep

Hi all I have a complex program that when under load will very reproducibly freeze every goroutine simultaneously. It then makes no progress at all, even if left for hours. I'm posting here because I don't know of anything that can cause this behavior so I don't even know where to begin

Re: [go-nuts] Float multiplication bug?

https://play.golang.org/p/0XRLg6-6uPk On Thu, Feb 22, 2018 at 1:09 PM, andrey mirtchovski wrote: > in the first Printf "area" is truncated. try %.40f to see the real > value, which is more like: > > 262256.4523014638689346611499786376953125 > > plugging that in as h2 will

Re: [go-nuts] vgo and enterprise GitHub servers

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

[go-nuts] math integer sizes

I see that the math/bits package has a UintSize constant, and math has Max types. Why doesn't math have MaxInt and MaxUint? Yes, I know that these are derivative by themselves, but can they be included in the standard library without breaking the Go Compatibility promise? -- You received

Re: [go-nuts] http.shutdownPollInterval documentation

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

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

On Tue, Feb 20, 2018 at 5:14 PM, Dave MacFarlane wrote: > I really like this, except for the claim that it the blog post that it > will eliminate vendoring and deprecate GOPATH and the problems that > will cause for backwards compatibility for things that are currently > using

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

On Tue, Feb 20, 2018 at 4:07 PM, David Anderson wrote: > On Tue, Feb 20, 2018 at 11:37 AM, Russ Cox wrote: > >> On Tue, Feb 20, 2018 at 1:55 PM, David Anderson wrote: >> >>> I love this. I want it now. >>> >> >> go get -u golang.org/x/vgo

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

On Thursday, February 22, 2018 at 6:43:07 AM UTC-5, alex@gmail.com wrote: > > Yup, the package I'm working on really cannot have 2 instances even in > different import paths as it deals with a shared resource and code that > must be run on the main thread. > So I have to choose between

[go-nuts] vgo and enterprise GitHub servers

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 <

Re: [go-nuts] Experience report on coming to Go from a C perspective

I like this, thanks for pointing me to it. I think that's a good way to go for about half of it; if make / new can be considered as well, that'd be great. I suppose adg's point still stands in terms of gofmt output and a detailed proposal? I agree such a change should only be considered for Go 2.

[go-nuts] Re: extract rsa-encrypted public-key from tls-certificate (pem-format)

Hi, I believe you want something like this: https://play.golang.org/p/IL8f5AqpeQ3 This example is quick and dirty, but it should be a good starting point for you. I am assuming that both public & private keys are RSA keys, for EC keys the process is similar. Also, if you decide to copy past

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

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

Re: [go-nuts] Experience report on coming to Go from a C perspective

You might be interested in https://golang.org/issue/12854 for maps, slices, and structs. (It wouldn't help with channels, because there is currently no such thing as a channel literal.) On Thursday, February 22, 2018 at 5:32:40 PM UTC-5, Devon H. O'Dell wrote: > > 2018-02-22 14:19 GMT-08:00

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

Is there a story for a module that changes domains, like when google code shutdown or moving to a custom domain for vanity import paths? Having directives to say "find earlier versions here" or "find later versions" here seems like it would help downgrades/upgrades. If one of those old domains

BSD Re: [go-nuts] Experience report on coming to Go from a C perspective

On Feb 22, 2018, at 2:16 PM, Devon H. O'Dell wrote: > > (Re-adding list in here with Bakul's okay.) > > 2018-02-22 12:27 GMT-08:00 Bakul Shah : >> On Thu, 22 Feb 2018 12:02:35 -0800 "Devon H. O'Dell" >> wrote: >>> Hi all, >>>

Re: [go-nuts] Float multiplication bug?

sorry, i just realized that i said 'area' but meant 'height' in my previous email. On Thu, Feb 22, 2018 at 2:09 PM, andrey mirtchovski wrote: > in the first Printf "area" is truncated. try %.40f to see the real > value, which is more like: > >

Re: [go-nuts] Experience report on coming to Go from a C perspective

2018-02-22 14:19 GMT-08:00 Caleb Spare : > I occasionally run into this, but in my experience it's exclusively with > maps: I think all of the cases I ran into this were for maps and channels. > - Initializing empty slices is ~never necessary; (in my opinion the > "members:

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

On Thu, Feb 22, 2018 at 10:27 PM wrote: > On Thursday, February 22, 2018 at 9:53:20 PM UTC+8, Axel Wagner wrote: >> >> Daisy chaining would mean I would only have to code API translations for >>> the latest API but then it's debug hell and if one version in the chain >>>

Re: [go-nuts] Experience report on coming to Go from a C perspective

I occasionally run into this, but in my experience it's exclusively with maps: - Initializing empty slices is ~never necessary; (in my opinion the "members: []int{}" from the blog post is a code smell). - Channels need initialization but that's where the important buffered vs. unbuffered choice

Re: [go-nuts] Experience report on coming to Go from a C perspective

(Re-adding list in here with Bakul's okay.) 2018-02-22 12:27 GMT-08:00 Bakul Shah : > On Thu, 22 Feb 2018 12:02:35 -0800 "Devon H. O'Dell" > wrote: >> Hi all, >> >> It's been some time since I really contributed much of anything to the >> project

Re: [go-nuts] Re: Experience report on coming to Go from a C perspective

Thanks for pointing this out; I wasn't aware of this new syntax. I think this gets to about halfway of what I'd hope for. That said, I'd really like to avoid needing to jump through the hoop of indirection for this. I occasionally find it hard to recognize what the type of a thing is due to heavy

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

I'm not sure where the issue is but I tried with 1.9 - both locally and in Travis it passes with the same code. https://github.com/miracl/gomiracl/compare/fix-build?expand=1 - code https://travis-ci.org/miracl/gomiracl/jobs/345000314 - build On Thursday, February 22, 2018 at 6:48:34 PM UTC+2,

[go-nuts] http.shutdownPollInterval documentation

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

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

On Thursday, February 22, 2018 at 9:53:20 PM UTC+8, Axel Wagner wrote: > > Daisy chaining would mean I would only have to code API translations for >> the latest API but then it's debug hell and if one version in the chain >> breaks, >> it means fixing all the newer versions. Also there's a

Re: [go-nuts] Float multiplication bug?

in the first Printf "area" is truncated. try %.40f to see the real value, which is more like: 262256.4523014638689346611499786376953125 plugging that in as h2 will result in 39709429597.0098280725069344043731689453125 (according to wolfram alpha) On Thu, Feb 22, 2018 at 1:32 PM,

[go-nuts] Float multiplication bug?

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

[go-nuts] Re: Experience report on coming to Go from a C perspective

Have you considered using the new type alias feature introduced in 1.9? Line so: https://play.golang.org/p/6HK8qcuh9UU This would allow you to change the type of the map in a singe place (the type alias) and all the *{}* or *make *would adapt appropriately. Disclaimer: I am not espousing this

[go-nuts] Experience report on coming to Go from a C perspective

Hi all, It's been some time since I really contributed much of anything to the project (sorry!), but after 8 years, I'm finally writing Go outside of the project itself (and outside of porting efforts). I was lamenting to some coworkers about the lack of a comparable feature to C's "malloc idiom"

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

On Thu, Feb 22, 2018 at 8:38 AM, Владислав Митов wrote: > > 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': >

[go-nuts] Build started to fail with 1.10

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;

[go-nuts] extract rsa-encrypted public-key from tls-certificate (pem-format)

Hi, What I have: - tls-certificate (x.509 format, pem encoded) - within the tls-certificate -> public-key (rsa encrypted) - corresponding private-key (pem encoded, rsa encrypted) What I want: - validate pem encoded private-keys // (something like 'openssl rsa -in client.key -check' ) -

[go-nuts] Re: All Forms of Wishful Generics

I agree that this is one of the two large risks. The other is whether the language remains comparatively easy to learn. The next largest problem after those two is "what exactly do you mean by generics"? Some people want code stenciling, like C++ (it's fast, it's easy to understand, code size

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

On Thu, Feb 22, 2018, 12:43 wrote: > On Thursday, February 22, 2018 at 5:29:23 PM UTC+8, Axel Wagner wrote: >> >> Have you read https://research.swtch.com/vgo-import? It talks about >> singletons and also how to solve that with different import paths. >> Note, that this is

Re: [go-nuts] Appreciating Go

Usually, the type theoretic basis is what is called a sum-type. They are corresponding to a logical OR or a '+' addition operation in algebra. A "struct" is rightfully a variant of a product-type, or a logical AND or a '*' multiplication operation in algebra[0]. Most (commonly used) programming

Re: [go-nuts] Appreciating Go

On Thu, Feb 22, 2018 at 4:56 AM, Steven Hartland wrote: > On 22/02/2018 09:46, andrewchambe...@gmail.com wrote: > > Just a list of things I like about Go, thanks everyone for the hard work: > > snip... > > Minor things that could be improved in order of importance: > > -

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

On Thursday, February 22, 2018 at 5:29:23 PM UTC+8, Axel Wagner wrote: > > Have you read https://research.swtch.com/vgo-import? It talks about > singletons and also how to solve that with different import paths. > Note, that this is also independent of *how* the different import paths > are

[go-nuts] Go Web app skeleton

Hello, For one of my projects I wanted to create first a sample Web app in Go with the full layers (authentication, authorization, views, databases) and with no framework (but with toolkits). It is not perfect but I want to share if it may help others: https://github.com/tbellembois/gowebskel

Re: [go-nuts] Appreciating Go

On 22/02/2018 09:46, andrewchambe...@gmail.com wrote: Just a list of things I like about Go, thanks everyone for the hard work: snip... Minor things that could be improved in order of importance: - Ways to express immutability ... as a concurrent language it can still be easy to make

[go-nuts] Appreciating Go

Just a list of things I like about Go, thanks everyone for the hard work: Good things go has: - Go has an extremely useful std library. - Go has the best backwards compatibility I have seen (I'm pretty sure code from go version 1.0 still works today.). - Go has the nicest code manipulation

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

On Thu, Feb 22, 2018 at 7:18 AM wrote: > I don't think changing the module name would be a good idea for singletons > tho. > Have you read https://research.swtch.com/vgo-import? It talks about singletons and also how to solve that with different import paths. Note, that

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

On Thu, Feb 22, 2018 at 9:50 AM dc0d wrote: > And the first idea is about having packages that does not harm the > environment (like by importing reflect or executing external commands), and > seems to be a feasible goal. > Apologies, I was ambiguous in my quote, I

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

Thanks Axel, You are right about env-vars and as I've noted, there might be security concerns. The main goal here was to represent an idea for the source of the import. It can be the module descriptor of vgo. And the first idea is about having packages that does not harm the environment (like

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

On Thu, Feb 22, 2018 at 7:10 AM dc0d wrote: > I'm looking forward to see this in official releases too! > > Also I would like to: > > - Have a mechanism for safe dependency packages (as in Safe-Tcl > - this implies it would

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

On Thu, Feb 22, 2018 at 4:21 AM David Anderson wrote: > Currently, per the vgo tour, the entire transitive closure gets updated, > which, per the article's definition, results in a low-fidelity build... If > you assume that the intent of `vgo get -u` was "the libraries I'm