Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

On Thu, 25 Oct 2018, 12:52 am Axel Wagner, wrote: > On Thu, Oct 25, 2018 at 12:39 AM roger peppe wrote: > >> I understand this argument. By putting some smarts into the compiler, we >> would hope that we can see benefits not just in our generated generic code, >> but also in other code that we'v

[go-nuts] Re: handling unexpected module path

Joe, There's a good chance your diagnosis is correct -- my understanding is the path used in an import statement is required to match up with the module path in the 'module' directive in the imported module's go.mod file. In general, I think some projects have switched back and forth between w

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

On Thu, Oct 25, 2018 at 12:39 AM roger peppe wrote: > I understand this argument. By putting some smarts into the compiler, we > would hope that we can see benefits not just in our generated generic code, > but also in other code that we've already written that uses generics. This > would be grea

Re: [go-nuts] websocket implentation in golang

Here's a sketch: https://gist.github.com/9nut/11052587 On Wed, Oct 24, 2018 at 4:20 AM sakthi apr wrote: > Hi, > > I'm developing web socket in golang that checks the database changes like > new data insert. > > if the new record added in table user will get notified at client side. > > Anyone

[go-nuts] handling unexpected module path

Hi all, I have a deeply nested dependency somewhere that depends on go-resty. When I do a go list in my module, I see this error. go: github.com/go-resty/resty@v1.10.0: parsing go.mod: unexpected module path "gopkg.in/resty.v1" go: error loading module requirements I checked out goresty and i

Re: [go-nuts] websocket implentation in golang

You can look at github.com/robaho/go-trader See webserver.go and book.js In this case, the server sends updates (market changes) to the subscribed clients unsolicited, but on an interval (so rapid changes on the server don’t flood the network). I believe yo

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

On Sun, 21 Oct 2018 at 13:53, Axel Wagner wrote: > Last addition: > > On Sun, Oct 21, 2018 at 2:03 PM roger peppe wrote: > >> Ah, I *think* I see where you might be coming from now. You're thinking >> that the compiler could do some kind of Go-to-Go transformation for generic >> functions so tha

Re: [go-nuts] Regarding contracts

On Wed, Oct 24, 2018 at 3:52 PM Andy Balholm wrote: > > What I’m doing with structural contracts is basically the same as what you’re > doing with struct and interface types as contracts, except that (I hope) the > syntax is a little clearer. > > I added the support for operators basically to av

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

On Sun, 21 Oct 2018 at 13:40, Axel Wagner wrote: > On Sun, Oct 21, 2018 at 2:03 PM roger peppe wrote: > >> Yes. The draft proposal says "generic functions, rather than generic >> types, can probably be compiled using an interface-based approach. That >> will optimize compile time, in that the pa

Re: [go-nuts] Go 2 Proposal Comments

Ian, thanks for commenting. I wonder if this might be viewed as motivation for "bigger, visible, clear" changes rather than nuanced ones. As a ship captain, I'm trained to take "early and effective action" to avoid problems. Not just to solve them, but to do so ina way that signals the other boat

Re: [go-nuts] Regarding contracts

What I’m doing with structural contracts is basically the same as what you’re doing with struct and interface types as contracts, except that (I hope) the syntax is a little clearer. I added the support for operators basically to avoid having the supportsEqual contract as a special case that n

Re: [go-nuts] Having trouble installing golint

It must have been a configuration issue on the remote server because it all works fine now. On Wednesday, 17 October 2018 22:05:48 UTC+1, Sam Whited wrote: > > TL;DR — you don't need to run the second command, just the first one. > > I'm sorry for being unclear. Go get looks up packages by their

Re: [go-nuts] Draft error handling design - could 'check' and 'handle' be 'contextual' keywords?

I don't think we'll see check in the next draft. A LOT of the feedback[1] suggests various ways to invoke a named handler. But these are awkward: check(name) f(a) check(name, f(a)) f(a) check name I hope check will be supplanted[2] by *symbol handler_name*, e.g. ?name = f(a); x(f?name(a))

Re: [go-nuts] Go 2 Proposal Comments

On Wed, Oct 24, 2018 at 10:05 AM, Michael Jones wrote: > > Agree on the industry dynamics observation--I remember too--but want to > raise another point of view on 100% backwards compatibility: when Go was > just a baby, in pre-1.0 days, there was exploration and new ideas. There was > also "Go Fi

Re: [go-nuts] New keywords and backwards compatibility

I like the idea. Simple. I think the go documentation needs to have similar @Since annotations like Java. I would also strongly suggest no breaking APIs - ever... > On Oct 24, 2018, at 2:14 PM, Ian Denhardt wrote: > > Hey all, > > Today I've seen a lot of messages re: concerns about adding ne

Re: [go-nuts] New keywords and backwards compatibility

On Wed, Oct 24, 2018 at 12:14 PM, Ian Denhardt wrote: > > Thoughts? Please read https://golang.org/issue/28221 and the background doc linked there. I suggest that you comment on that issue, which is exactly about the topics you raise here. Thanks. Ian -- You received this message because you

[go-nuts] Re: New keywords and backwards compatibility

I suggested a //go:lang directive to select non-backwards-compatible features on the issue below, but it was rejected. https://github.com/golang/go/issues/28221 Note also the semver suggestion that each new version which provides non-backwards-compatible features should get a new major version,

[go-nuts] New keywords and backwards compatibility

Hey all, Today I've seen a lot of messages re: concerns about adding new keywords and breaking backwards compatibility. People have floated a couple approaches to avoiding breakage. But I feel like all of them that I've seen so far will make code confusing. I'd like to propose an alternative, whic

[go-nuts] Re: Go 2 Proposal Comments

I didn't know that Ian had written this proposal so thanks for linking to it. Although I haven't had time to read it in detail, I certainly agree with the tenor of what he's saying. I know more about C# than Java and the language team there have always been paranoid about not breaking compatib

Re: [go-nuts] Using default in select causes a deadlock

On Wed, Oct 24, 2018 at 11:17 AM Sathish VJ wrote: > > Thank you. Would you have an explanation for why it works so differently > from using default? The codepath that causes the deadlock is : - main reads from c - f() runs select, quit is not writable, so selects default, which starts waitin

Re: [go-nuts] Using default in select causes a deadlock

Thank you. Would you have an explanation for why it works so differently from using default? On Wednesday, 24 October 2018 22:44:26 UTC+5:30, Burak Serdar wrote: > > You can do this instead: > > https://play.golang.org/p/avMIyYlwxbF > On Wed, Oct 24, 2018 at 11:05 AM Sathish VJ > wrote: > >

Re: [go-nuts] Using default in select causes a deadlock

You can do this instead: https://play.golang.org/p/avMIyYlwxbF On Wed, Oct 24, 2018 at 11:05 AM Sathish VJ wrote: > > This is a program where the receiver is asking the sender to close after > receiving 1 value. Using default for the sending (line 34) causes the code > to deadlock while even a

[go-nuts] Using default in select causes a deadlock

This is a program where the receiver is asking the sender to close after receiving 1 value. Using default for the sending (line 34) causes the code to deadlock while even a timeout of a nanosecond causes it to be ok. I don't want to time the sending though. Is there a better option to sequen

Re: [go-nuts] Go 2 Proposal Comments

Agree on the industry dynamics observation--I remember too--but want to raise another point of view on 100% backwards compatibility: when Go was just a baby, in pre-1.0 days, there was exploration and new ideas. There was also "Go Fix" to rewrite "go of the past" as "go of today." This seemed geniu

Re: [go-nuts] Go 2 Proposal Comments

Btw, for those that are interested, enum was added in Java5, the same time they added generics. It constituted the 3rd revision to the JLS. > On Oct 24, 2018, at 11:39 AM, robert engels wrote: > > Also, I wouldn’t discount the ‘binary runs with the latest JVM’ doesn’t apply > to Go. > > As I

Re: [go-nuts] Q16.16 fixed point numbers in go

https://en.wikipedia.org/wiki/Q_(number_format) says it all. you can use fixed point all the way...just shift after multiplies and before divides and use double-width (int32) or wider math. On Mon, Oct 22, 2018 at 3:24 PM Vasiliy Tolstov wrote: > Thanks for suggestions. > If somebody can look a

Re: [go-nuts] Regarding contracts

On Wed, Oct 24, 2018 at 10:22 AM Andy Balholm wrote: > > Here’s my attempt at streamlining it, as well as adding a way to deal with > the operator/method dichotomy: > https://gist.github.com/andybalholm/8165da83c10a48e56590c96542e93ff2 Thanks! However, I think yours is a somewhat different ap

Re: [go-nuts] Go 2 Proposal Comments

Also, I wouldn’t discount the ‘binary runs with the latest JVM’ doesn’t apply to Go. As I pointed out in an earlier email, I think the future of Go is that the shipped binary will be runtime linked against the standard library and runtime. This is by far the easier way to deliver security patch

Re: [go-nuts] Go 2 Proposal Comments

I did some research, you are correct that enum was not in JLS 1.0, nor was it a reserved word. Can’t find early later specifications to determine when it was actually added though. I don’t know - I was against how generics were done in Java originally as well, but after using them for a while,

Re: [go-nuts] Go 2 Proposal Comments

On Wed, Oct 24, 2018 at 10:21 AM robert engels wrote: > > I think enum was a reserved word from the beginning - like goto - if not it > was VERY early on when it was added. Still, the code would of run on the > latest JVM, it might not of compiled. Outside of that possible case, I can’t > think

Re: [go-nuts] Regarding contracts

Here’s my attempt at streamlining it, as well as adding a way to deal with the operator/method dichotomy: https://gist.github.com/andybalholm/8165da83c10a48e56590c96542e93ff2 Andy > On Oct 23, 2018, at 9:37 AM, Burak Serdar

Re: [go-nuts] Go 2 Proposal Comments

I think enum was a reserved word from the beginning - like goto - if not it was VERY early on when it was added. Still, the code would of run on the latest JVM, it might not of compiled. Outside of that possible case, I can’t think of another keyword that has been added - maybe the recent additi

Re: [go-nuts] interface array and ... operator

Eh, actially the other discusser said that. Me not. I explained why A does not work. On Wed, Oct 24, 2018, 18:08 Jan Mercl <0xj...@gmail.com> wrote: > Nobody said that. > > On Wed, Oct 24, 2018, 18:04 robert engels wrote: > >> I’m confused… it is A that doesn’t work, and B works… everyone keeps

Re: [go-nuts] interface array and ... operator

I quote So in the OP's example https://play.golang.org/p/59bpr8TCIge , the function A() is assigning a []string to the variadic ...[]interface{}. Since string is assignable to interface{}. this is fine. The function B() is assigning a []interface{} to the

Re: [go-nuts] Go 2 Proposal Comments

On Wed, Oct 24, 2018 at 9:59 AM robert engels wrote: > > To this day, you can take a “binary” written for Java 1.0 and it will run > under the latest JRE. You can compile Java 1.0 source code with the latest > compiler. This is an amazing accomplishment that can’t be understated. That is not ex

Re: [go-nuts] interface array and ... operator

Nobody said that. On Wed, Oct 24, 2018, 18:04 robert engels wrote: > I’m confused… it is A that doesn’t work, and B works… everyone keeps > stating that B doesn’t work and A works…. > > On Oct 24, 2018, at 10:55 AM, jake6...@gmail.com wrote: > > > That is correct. The relevant part of > https://

Re: [go-nuts] interface array and ... operator

I’m confused… it is A that doesn’t work, and B works… everyone keeps stating that B doesn’t work and A works…. > On Oct 24, 2018, at 10:55 AM, jake6...@gmail.com wrote: > > That is correct. The relevant part of > https://golang.org/ref/spec#Passing_arguments_to_..._parameters >

[go-nuts] Go 2 Proposal Comments

I'd like to offer a few comments on Ian's https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md Since the author admits the least amount of experience with Java, maybe my facts, and many op

Re: [go-nuts] interface array and ... operator

That is correct. The relevant part of https://golang.org/ref/spec#Passing_arguments_to_..._parameters is where it says: " respective parameter passing rules apply". This links to https://golang.org/ref/spec#Passing_arguments_to_

Re: [go-nuts] Draft error handling design - could 'check' and 'handle' be 'contextual' keywords?

Hmm, interesting idea! Presumably, that would still work if 'check' were declared as a local variable within the same function *after* all the error handling stuff, as the compiler would detect it on first pass. I wondered myself about having some sort of pragma or pseudo-import (say: import .

re:[go-nuts] liteide x35 released! Go1.11 modules support.

Please download LiteIDE x35.1Fix gocode types info parse source \r\n bug. Fix Golang editor jump import lines bug. -- 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

Re: [go-nuts] Draft error handling design - could 'check' and 'handle' be 'contextual' keywords?

On Wed, Oct 24, 2018 at 3:49 AM, alanfo wrote: > > I quite like the draft error handling design and haven't (so far) suggested > that any changes be made. > > However, one aspect I don't like is 'check' and 'handle' having to be > keywords which means that the design is not Go 1 compatible. Also,

Re: [go-nuts] Calendar Integration Values

Thank You. I was afraid that would be the answer, but my research could not match yours. I will keep looking; however there does have to be a better way to provide API access to outside resources without involving my domain users . I always use a service account with DWD enabled and use my admi

Re: [go-nuts] Failed iterator proposals?

On Wed, Oct 24, 2018 at 2:35 PM Eric S. Raymond wrote: > Axel Wagner : > > The key term was "occasionally". I don't know how often "iterators that > > don't need any error handling or cleanup" comes up, but I'd imagine it to > > be pretty rare. In Python, for example, this might be a bit differen

Re: [go-nuts] interface array and ... operator

But it is the varadic one that works according to OP. > On Oct 24, 2018, at 4:19 AM, Jan Mercl <0xj...@gmail.com> wrote: > > On Wed, Oct 24, 2018 at 7:34 AM Mayank Jha wrote: > > > why does A() not work while B works here, > > https://play.golang.org/p/59bpr8TCIge > > Type mismatch. The com

Re: [go-nuts] Failed iterator proposals?

On Mon, Oct 22, 2018 at 2:41 AM Eric Raymond wrote: > There's an obvious, clumsy way to do this by having a factory pass back a stateful iterator object: > > for iterator := IteratorFactory(selector); iterator.Continue();iterator.Next(){ >DoSomethingWith(iterator.Value()) > } > > What one

[go-nuts] Powerful text query language GraphQuery

GraphQuery [image: CircleCI] [image: Go Report Card] [image: Build Status] [image: Coverage Status]

Re: [go-nuts] Failed iterator proposals?

Axel Wagner : > The key term was "occasionally". I don't know how often "iterators that > don't need any error handling or cleanup" comes up, but I'd imagine it to > be pretty rare. In Python, for example, this might be a bit different, > because the iterator can just throw. And if you actually don

[go-nuts] websocket implentation in golang

Hi, I'm developing web socket in golang that checks the database changes like new data insert. if the new record added in table user will get notified at client side. Anyone have idea plz share with me. Thanks -- You received this message because you are subscribed to the Google Groups

[go-nuts] Draft error handling design - could 'check' and 'handle' be 'contextual' keywords?

I quite like the draft error handling design and haven't (so far) suggested that any changes be made. However, one aspect I don't like is 'check' and 'handle' having to be keywords which means that the design is not Go 1 compatible. Also, whilst I agree that these words are probably the best on

Re: [go-nuts] interface array and ... operator

On Wed, Oct 24, 2018 at 7:34 AM Mayank Jha wrote: > why does A() not work while B works here, https://play.golang.org/p/59bpr8TCIge Type mismatch. The compiler is clear about it: prog.go:8:12: cannot use s (type []string) as type []interface {} in append >From https://golang.org/ref/sp

Re: [go-nuts] Sharing data via Mutex vs. Channel

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

Re: [go-nuts] Regarding contracts

Maybe it's worth adding to: https://github.com/golang/go/wiki/Go2GenericsFeedback On Tuesday, 23 October 2018 17:37:40 UTC+1, Burak Serdar wrote: > > I typed this up in a more organized way, and it turned out to be an > alternative declaration for contracts without touching the generics > parts

Re: [go-nuts] Re: do you use binary-only packages?

On 10/19/18, Ian Lance Taylor wrote: > On Fri, Oct 19, 2018 at 1:14 AM, Sam Mortimer > wrote: >> >> On Thursday, October 18, 2018 at 4:28:23 PM UTC-7, Ian Lance Taylor >> wrote: >>> >>> The question is: is anybody actually doing this? Is anybody seriously >>> thinking about it? >> >> Unhelpfully

Re: [go-nuts] Re: do you use binary-only packages?

On 10/19/18, Ian Lance Taylor wrote: > On Fri, Oct 19, 2018 at 1:14 AM, Sam Mortimer > wrote: >> >> On Thursday, October 18, 2018 at 4:28:23 PM UTC-7, Ian Lance Taylor >> wrote: >>> >>> The question is: is anybody actually doing this? Is anybody seriously >>> thinking about it? >> >> Unhelpfully