Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread 'Carla Pfaff' via golang-nuts
On Sunday, 26 July 2020 at 07:06:16 UTC+2 Carla Pfaff wrote: > Maybe gofmt could rewrite "interface{}" to "any", so there won't even be > such a question for new code. > When I think about it, that's probably not possible for gofmt to do in a safe way. -- You received this message because

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread 'Carla Pfaff' via golang-nuts
On Sunday, 26 July 2020 at 03:13:30 UTC+2 Denis Cheremisov wrote: > The bad with *any* in builtins is there will be questions "why you use > interface{}" if there's builtin *any?*", etc. If Go has generics I expect that people will use "interface{}"/"any" a lot less outside of type parameter

[go-nuts] Re: How can I fork a module that uses /internal ?

2020-07-25 Thread Brad Beveridge
Thank you very much! I have no idea why I thought I needed to change go.mod. I did run into some strange effects changing my local version back to "sclevine" though - I also needed to remove the cached versions in *go/pkg*. Thanks again! Brad On Sunday, 26 July 2020 at 13:03:22 UTC+12 Denis

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread Denis Cheremisov
I actually mean something different. The bad with *any* in builtins is there will be questions "why you use interface{}" if there's builtin *any?*", etc. I mean these will be different AST nodes, there will be *type GenericAny struct {* *Name *ast.Lit* *}* and *type Generic struct {* *

[go-nuts] Re: How can I fork a module that uses /internal ?

2020-07-25 Thread Denis Cheremisov
As soon as I understand you can just keep their module name in `go.mod` and that's it. воскресенье, 26 июля 2020 г. в 03:46:15 UTC+3, brad.be...@gmail.com: > Hi folks. I was unable to find a good answer online already. The closest > I found was >

[go-nuts] How can I fork a module that uses /internal ?

2020-07-25 Thread brad . beveridge
Hi folks. I was unable to find a good answer online already. The closest I found was https://stackoverflow.com/questions/14323872/using-forked-package-import-in-go which suggests using the replace directive in go.mod. I am using Go 1.14, with all projects located outside of GOPATH. My

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread 'Carla Pfaff' via golang-nuts
I don't see why it should be in the grammar. Just a regular type alias for interface{} in the builtin scope, a regular predeclared identifier. It wouldn't break anyone's code. If someone already has an 'any' type or variable in their package their version shadows the builtin one, and they can

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread DrGo
I too think that T any is more readable than the overloaded type in type T especially if it means that I won’t have to remember when it’s Ok to drop type and when it’s not On Saturday, July 25, 2020 at 4:47:17 PM UTC-5 Denis Cheremisov wrote: > Great catch! I would say I really like it! > >

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread Denis Cheremisov
Btw, it `any` suffix can be a part of grammar, I mean something like *GenericParam = Lit [',' Lit]* 'any' | Lit [',' Lit]* Ident* where *any* can be replaced with an actual *any* if there's one in a scope. воскресенье, 26 июля 2020 г. в 00:47:17 UTC+3, Denis Cheremisov: > Great catch! I would

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread Denis Cheremisov
Great catch! I would say I really like it! суббота, 25 июля 2020 г. в 23:37:39 UTC+3, Carla Pfaff: > I know it's common to have no constraints, but "[Elem any]" is even one > character shorter than "[type Elem]". I rewrote the function signatures > from slices.go2 in this way, and it doesn't

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread Denis Cheremisov
I look at what Carla did write and it feels ... good. I don't know, it may be not for everyone, but for me [T any] looks cleaner than [type T]. Probably I see `[` and understand this is generic params, then `T` and I immediately understand this is how the generic type denoted. A final touch, I

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread 'Carla Pfaff' via golang-nuts
On Saturday, 25 July 2020 at 22:22:24 UTC+2 Ian Lance Taylor wrote: > Note that in this way constraints on type parameters are different > from types of regular parameters. It makes no sense to speak of a > regular parameter with no type. > In regular parameter lists interface{} has this role,

Re: [go-nuts] [generics] Feedback on optional type keyword experiment

2020-07-25 Thread Bakul Shah
I like it! BTW, I don't understand the meaning of this comment in the commit log: > >> Experiment: Make "type" keyword optional in generic type declarations when > >> it is clear that we can't have an array type declaration. It is talking about defining generic arrays, where one parameter may

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread 'Carla Pfaff' via golang-nuts
There's already a precedent of a builtin type alias in Go with "type rune = int32" https://golang.org/pkg/builtin/#rune and "any" would make many regular parameter lists shorter as well. On Saturday, 25 July 2020 at 22:37:39 UTC+2 Carla Pfaff wrote: > I know it's common to have no constraints,

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread 'Carla Pfaff' via golang-nuts
I know it's common to have no constraints, but "[Elem any]" is even one character shorter than "[type Elem]". I rewrote the function signatures from slices.go2 in this way, and it doesn't feel painful. This already works on the go2go playground: https://go2goplay.golang.org/p/IQV5LTAIuDr On

Re: [go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread Ian Lance Taylor
On Sat, Jul 25, 2020 at 11:47 AM 'Carla Pfaff' via golang-nuts wrote: > > To expand on my post: > It would be very consistent with the structure of regular parameter lists. > Just like every parameter in a regular parameter list must have a type (with > the exception of multiple consecutive

[go-nuts] I have own issue my whole project follow relative schema ./db

2020-07-25 Thread Ali Hassan
I have own issue my whole project follow relative schema (./db) , but I want like this . import ( github.com/username/projecr-name,package-name). How ??? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

[go-nuts] Re: [generics] Feedback on optional type keyword experiment

2020-07-25 Thread 'Carla Pfaff' via golang-nuts
To expand on my post: It would be very consistent with the structure of regular parameter lists. Just like every parameter in a regular parameter list must have a type (with the exception of multiple consecutive parameters having the same type), every type parameter in a type parameter list

[go-nuts] [generics] Feedback on optional type keyword experiment

2020-07-25 Thread 'Carla Pfaff' via golang-nuts
I just discovered the experiment to make the "type" keyword optional in certain cases on the dev.go2go branch. The commit message says: --- Experiment: Make "type" keyword optional in generic type declarations when it is clear that we can't have an array type declaration. This is the

[go-nuts] Re: go module @latest found but does not contain package

2020-07-25 Thread Tong Sun
Thanks a lot Brian! I upgraded to go version go1.14.3 linux/amd64 in Ubuntu 20.04 LTS and now the problem is gone. thx! On Saturday, July 25, 2020 at 12:25:15 PM UTC-4, Brian Candler wrote: > > Works fine for me. Inside an empty directory: > > $ wget >

[go-nuts] Re: minimum linux kernel version that can run latest golang

2020-07-25 Thread jake...@gmail.com
See the list in https://golang.org/doc/install On Saturday, July 25, 2020 at 1:31:07 AM UTC-4 cuiw...@gmail.com wrote: > what is the minimum version of linux kernel that can run golang? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

[go-nuts] Re: go module @latest found but does not contain package

2020-07-25 Thread Brian Candler
Works fine for me. Inside an empty directory: $ wget https://raw.githubusercontent.com/mkideal/cli/master/_examples/015-file/main.go $ go mod init github.com/mkideal/cli/015-file go: creating new go.mod: module github.com/mkideal/cli/015-file $ go build go: finding module for package

[go-nuts] Re: Generics and parentheses

2020-07-25 Thread jake...@gmail.com
Presumably the instantiation of generic types and functions will be a lot more common than the declarations. How does your proposal handle those? (FWIW, I'm fine with square brackets, or really anything other than parens.) On Monday, July 20, 2020 at 12:42:13 PM UTC-4 Geoff Speicher wrote: >

Re: [go-nuts] JSON stream parsing help

2020-07-25 Thread Amnon BC
Awesome, thanks! On Sat, Jul 25, 2020 at 3:50 PM burak serdar wrote: > On Sat, Jul 25, 2020 at 6:09 AM Amnon wrote: > > > > Hi, > > > > I need to consume a stream of json objects. > > But unfortunately the json objects are separated by commas. > > > > Is there any simple way I can convince the

Re: [go-nuts] JSON stream parsing help

2020-07-25 Thread burak serdar
On Sat, Jul 25, 2020 at 6:09 AM Amnon wrote: > > Hi, > > I need to consume a stream of json objects. > But unfortunately the json objects are separated by commas. > > Is there any simple way I can convince the json.Decorder to skip the comma > after each successful call to decode? You have to

[go-nuts] Re: go module @latest found but does not contain package

2020-07-25 Thread antoniosun001
On Friday, July 24, 2020 at 1:08:06 PM UTC-4, Tong Sun wrote: > > Hi, > > How to get around the following, go module @latest found but does not > contain package? > > $ cd /tmp/015-file > > $ GO111MODULE=on > > $ go mod init github.com/mkideal/cli/015-file > go: creating new go.mod: module

Re: [go-nuts] A question about copying

2020-07-25 Thread chri...@surlykke.dk
Aha, I see. Thanks for explaining. br. Chr. lørdag den 25. juli 2020 kl. 10.56.35 UTC+2 skrev Jan Mercl: > On Sat, Jul 25, 2020 at 10:09 AM chri...@surlykke.dk > wrote: > > > Is this something I should have deduced from the language spec? > > https://golang.org/ref/spec#Address_operators > >

[go-nuts] JSON stream parsing help

2020-07-25 Thread Amnon
Hi, I need to consume a stream of json objects. But unfortunately the json objects are separated by commas. Is there any simple way I can convince the json.Decorder to skip the comma after each successful call to decode? My code looks like for { var a st err := dec.Decode() if err == io.EOF {

[go-nuts] Re: Go 1.15 Release Candidate 1 is released

2020-07-25 Thread Amnon
Cool. go1.15rc1 gives a 8% speedup on my tests. On Friday, 24 July 2020 20:21:50 UTC+1, Alexander Rakoczy wrote: > > Hello gophers, > > We have just released go1.15rc1, a release candidate version of Go 1.15. > It is cut from release-branch.go1.15 at the revision tagged go1.15rc1. > > Please

[go-nuts] Re: go module @latest found but does not contain package

2020-07-25 Thread Brian Candler
What's in your "main.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. To view this discussion on the web visit

Re: [go-nuts] Busy synchronization wait seems to behave differently on 1.13 and 1.14

2020-07-25 Thread Jesper Louis Andersen
This is probably due to improvements in preemption. Garbage collectors often need some linearizable checkpoint (or an atomic commit point) where every CPU core agrees on a state. For instance, enabling a write barrier on the heap. Back in the day, this was achieved on communication via channels,

Re: [go-nuts] Busy synchronization wait seems to behave differently on 1.13 and 1.14

2020-07-25 Thread Martin Schnabel
I am not certain but the reason probably is the change to go-routine preemption in 1.14. From https://golang.org/doc/go1.14#runtime … Goroutines are now asynchronously preemptible. As a result, loops without function calls no longer potentially deadlock the scheduler or significantly delay

Re: [go-nuts] A question about copying

2020-07-25 Thread Jan Mercl
On Sat, Jul 25, 2020 at 10:09 AM chri...@surlykke.dk wrote: > Is this something I should have deduced from the language spec? https://golang.org/ref/spec#Address_operators For an operand x of type T, the address operation generates a pointer of type *T to x. The operand must be

Re: [go-nuts] A question about copying

2020-07-25 Thread Aleksey Tulinov
You are probably thinking about code like this: var f2 = *f1 Which will make a copy, although not because `f1` is dereferenced, but because `=` was called on a value. Dereferencing a pointer gives a reference to the same value, taking address of the same value will produce a pointer to the same

Re: [go-nuts] A question about copying

2020-07-25 Thread 'Dan Kortschak' via golang-nuts
On Sat, 2020-07-25 at 01:09 -0700, chri...@surlykke.dk wrote: > &(*f1) > > would, first, create a copy of *f1, and then a pointer to that copy, > but evidently f2 becomes a pointer to the same struct as f1. Is this > something I should have deduced from the language spec? &(*p) says "give me

[go-nuts] A question about copying

2020-07-25 Thread chri...@surlykke.dk
When running this program: package main import ( "fmt" ) type Foo struct { i int } func main() { var f1 = {i: 0} var f2 = &(*f1) f2.i = 1 fmt.Println(f1, f2) } it yields: &{1} &{1} (https://play.golang.org/p/qKtURokUCEW) I (naively) assumed that the expression &(*f1) would, first,

Re: [go-nuts] minimum linux kernel version that can run latest golang

2020-07-25 Thread Andrei Tudor Călin
2.6.23, for most architectures, as far as I know. On Sat, Jul 25, 2020 at 8:31 AM xie cui wrote: > what is the minimum version of linux kernel that can run golang? > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from

[go-nuts] Busy synchronization wait seems to behave differently on 1.13 and 1.14

2020-07-25 Thread Groups Discussion
Hi all, writing a stress test case for one of my apps I noticed a very strange thing: my test case works well on go 1.14 but it doesn't work on go 1.13. I wrote a minimal reproducer https://play.golang.org/p/uHkKMINncUB to make it work on go 1.13 I have to add the sleep at line 41. In Go