Re: [go-nuts] Does the Wait function of sync.WaitGroup behave as a memory barrier?

On Sat, Aug 26, 2017 at 4:34 AM, honzajde wrote: > > Back to the primary question: Is it safe to read condition if I add a break > to the loop like this? Yes. sync.WaitGroup.Wait would be useless if it didn't provide a happens-before relationship from changes made in the

[go-nuts] Re: Go 1.9 introduced error on UDP Multicast JoinGroup

https://github.com/golang/go/issues I don't see an existing issue for this. I would file one with details about how to reproduce. -- 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,

Re: [go-nuts] Re: Generics and readability

Someone who can summarize the lisp experience woud be usefull here: generate-and-execute is that language's equivalent of preprocessors and code generators, and has been around the beginning of the language. -- You received this message because you are subscribed to the Google Groups

[go-nuts] Re: Go 1.9 introduced error on UDP Multicast JoinGroup

No. I just downloaded and used 1.9 on its release last week. I've reverted to 1.8.3 for now and, as mentioned, it's working fine for me. On Sunday, 27 August 2017 16:28:48 UTC-7, Pierre Durand wrote: > > Did you test Go 1.9 betas or RCs ? > > Le lundi 28 août 2017 01:14:20 UTC+2,

[go-nuts] Re: Go 1.9 introduced error on UDP Multicast JoinGroup

Did you test Go 1.9 betas or RCs ? Le lundi 28 août 2017 01:14:20 UTC+2, oldCoderException a écrit : > > Hi all, > > I upgraded to Go 1.9 and since then UDP multicast code that has been > running fine for over a year is now failing on JoinGroup. I run this > program on linux Mint 18 as root

[go-nuts] Go 1.9 introduced error on UDP Multicast JoinGroup

Hi all, I upgraded to Go 1.9 and since then UDP multicast code that has been running fine for over a year is now failing on JoinGroup. I run this program on linux Mint 18 as root (using sudo), both for the multicast permissions and also to allow listening on TCP port 80 and redirecting to port

Re: [go-nuts] Why does assigning a function variable to a method value allocate memory?

I've long liked using ragel, but I have to say that with the projects bus factor and recent removal of Go code generation, it's less attractive than it used to be. On Wed, 2017-08-23 at 23:56 -0700, Tamás Gulácsi wrote: > See ragel for an fsm generator! -- You received this message because you

Re: [go-nuts] Re: Generics and readability

On Sat, Aug 26, 2017 at 7:03 PM wrote: > > Generics user here, since Bjarne Stroustrup's CFront, the very first C++ > compiler. > > Whenever you use complex idioms you reduce the amount of people able to > understand your code and able to mantain it. The simpler the code, the

Re: [go-nuts] Re: Generics and readability

On Sun, Aug 27, 2017, 18:28 Tristan Colgate wrote: Code generation feels more idiomatic to Go. I'm tempted by some kind of > package level generics, but I'm terrified that the standard library might > end up using them. > Stdlib uses code generation since its first public

Re: [go-nuts] Re: Generics and readability

in my concern i could agree with everyone. so it does not go anywhere, does it ? Axel resumes it well. I d just add one notion, complexity to build the desired generator. Even though a great work has been made so golang compile in go, it is not an easy api to handle. So if go intends to

Re: [go-nuts] Re: Generics and readability

It would be great to hear from those that have written extensive code generation tools as to what changes, if any, Go2 could bring to make code generation easier. Code generation feels more idiomatic to Go. I'm tempted by some kind of package level generics, but I'm terrified that the standard

Re: [go-nuts] Re: Generics and readability

While having generics as part of the language and doing the code-gen in the compiler has definite advantages (ease of use and potentially better optimization of the generated code), doing it as a separate tool *also* has advantages. For example, this way no one is bound to whatever notion of

Re: [go-nuts] Re: Generics and readability

Interchanging the particular example and the general principle it shows, allows to easily conclude almost anything, right. On Sun, Aug 27, 2017, 17:08 wrote: > > That's how C++ started. > > And that's also why C++ is the ugly monster than it is today; with a > design that

Re: [go-nuts] Re: Generics and readability

> That's how C++ started. And that's also why C++ is the ugly monster than it is today; with a design that wasn't quite thought thoroughly. Talking about C++ like it's an example to follow is just preposterous. Le dimanche 27 août 2017 16:25:54 UTC+2, Jan Mercl a écrit : > > And there's

Re: [go-nuts] Re: Generics and readability

And there's nothing wrong in it. That's how C++ started. Codegen allows for easier protoyping throwaway experiments. Writing a full blown compiler and realizing afterwards a better language/feature design costs probably much more work. On Sun, Aug 27, 2017, 15:55 wrote: >

Re: [go-nuts] Re: Generics and readability

Codegen can do 100% of what any compiler can do. On Sun, Aug 27, 2017, 14:54 wrote: > > A lot of people consider code gen a second class solution when compared > to a more traditional generics implementation. I don't think so. Code > generation can be very effective. No

[go-nuts] Re: Generics and readability

> A lot of people consider code gen a second class solution when compared to a more traditional generics implementation. I don't think so. Code generation can be very effective. No major concerns about indecipherable error messages. When in doubt you can inspect the generated code to

[go-nuts] Re: Excel XLSX to read/write without losing of formatting

Hope you will have time :) I still have some todos - like adding "drawing" and etc, but I really worry about - how it would be easy to contribute, because I really don't want another library that hard to support/improve On Sunday, August 27, 2017 at 9:34:51 AM UTC+3, Andrey Gayvoronsky wrote:

[go-nuts] goconstraint: package for minimum Go version constraints at compile time

Hey there, I was working on updating a piece of software I maintain tonight to use Go 1.9, specifically I needed the monotonic time source in time.Time. I decided I wanted to prevent my software from being compiled on anything less than Go 1.9, because the behavior could be unexpected when a

[go-nuts] Unused function in package

Thanks Florin. Your explanation makes a lot of sense. I'll also write tests going forward so that all exported functions are "used" at least once. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

Re: [go-nuts] Unused function in package

Gogland does not use go vet. -- 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

[go-nuts] Unused function in package

There are chances that other function names will change the signature to match interfaces in your GOPATH, in which case Gogland will not mark the function as unused since it won't know if it's needed to implement that interface or not (given how interfaces work in Go). Since Gogland looks in

[go-nuts] Excel XLSX to read/write without losing of formatting

Hi guys, I know that there are few libs already here, but sadly I could not get any that would respects existing styles. So here is new attempt to get decent lib to work with xlsx: https://github.com/plandem/xlsx Would like to hear your thoughts -- You received this message because you are