Re: [go-nuts] Re: What's the maximum array length?

On Sat, Oct 29, 2022 at 12:11 PM Kurtis Rader wrote: Did you not see my reply pointing out the same thing? That is, given a particular platform and executable format the limit is likely to be much less than math.MaxInt. Alternatively, was my reply not clear about the practical versus theoretical

Re: [go-nuts] Re: Go 1.19 average goroutine stack

On Thu, Aug 18, 2022 at 5:11 PM Jan Mercl <0xj...@gmail.com> wrote: > On Thu, Aug 18, 2022 at 10:34 AM T L wrote: > > > When I investigate something, I ask questions in communities firstly, to > save time. > > To save your time at the expense of more time wasted by

Re: [go-nuts] Re: Go 1.19 average goroutine stack

On Thu, Aug 18, 2022 at 11:30 AM Kurtis Rader wrote: > On Wed, Aug 17, 2022 at 8:18 PM tapi...@gmail.com > wrote: > >> I'm a bit wondering about how the following case will be affected by the >> change: >> 1. Initially, there is one goroutine, which stack size is large at the >> time of a GC

Re: [go-nuts] Is this a known problem?

On Fri, Nov 12, 2021 at 11:54 PM Axel Wagner wrote: > Oh, sorry, I just re-read. Your example still requires `range` to return > distinct types, so that probably shouldn't work. > Not this reason: func Bar[T []byte|map[int]byte](s T) { for i, v := range s { _, _ = i, v} // cannot range

Re: [go-nuts] How the scopes of type parameters are defined?

This one compiles okay: func Bar2[T any](x T) T { { var T = x // T redeclared in this block return T } } So the parameter type is declared at the local top block? On Fri, Nov 12, 2021 at 9:43 PM T L wrote: > It is strange that my recent comments are deleted automatica

Re: [go-nuts] How the scopes of type parameters are defined?

It is strange that my recent comments are deleted automatically if they are posted from the web interface. But now from the email interface. On Fri, Nov 12, 2021 at 9:40 PM T L wrote: > Are the followings also intended? > > func Foo[T any](T T) T { // (the 2nd) T redeclared in t

Re: [go-nuts] How the scopes of type parameters are defined?

Are the followings also intended? func Foo[T any](T T) T { // (the 2nd) T redeclared in this block return T // T (type) is not an expression } func Bar[T any](x T) T { var T = x // T redeclared in this block return T } On Fri, Nov 12, 2021 at 6:03 PM Axel Wagner wrote: > > > On Fri,

[go-nuts] Re: An intresting behaviour about number of allocations in []byte->string conversions

Sorry, I temporarily switch to Go 1.3. The result is constantly 0 0 1 for Go 1.15 when N > 2. On Saturday, August 15, 2020 at 12:30:32 AM UTC-4, T L wrote: > > > package main > > import "fmt" > import "bytes" > import "testing" > > c

[go-nuts] An intresting behaviour about number of allocations in []byte->string conversions

package main import "fmt" import "bytes" import "testing" const N = 0 var name = bytes.Repeat([]byte{'x'}, N) var m = make(map[string]string, 10) var s string func f() { s = m[string(name)] } func g() { key := string(name) s = m[key] } func h() { m[string(name)] = "Golang" }

Re: [go-nuts] Re: [generics] how to constraint a type must be a map or a slice?

On Monday, June 22, 2020 at 1:25:33 PM UTC-4, Ian Lance Taylor wrote: > > On Mon, Jun 22, 2020 at 8:49 AM T L > > wrote: > > > > One example is the above Print function example. > > Another example I current get is to iterate and print > > all the key an

Re: [go-nuts] [generics] Should convertibility and comparibility of two types be two kinds of constraints?

On Sunday, June 21, 2020 at 11:21:29 PM UTC-4, Ian Lance Taylor wrote: > > On Sat, Jun 20, 2020 at 7:30 PM T L > > wrote: > > > > On Saturday, June 20, 2020 at 4:48:07 PM UTC-4, Ian Lance Taylor wrote: > >> > >> On Sat, Jun 20, 2020 at 8:26

Re: [go-nuts] Re: [generics] how to constraint a type must be a map or a slice?

On Saturday, June 20, 2020 at 3:08:42 PM UTC-4, David Finkel wrote: > > > > On Sat, Jun 20, 2020 at 11:03 AM T L > > wrote: > >> >> >> On Saturday, June 20, 2020 at 10:21:56 AM UTC-4, Axel Wagner wrote: >>> >>> I would assume it's

Re: [go-nuts] [generics] Should convertibility and comparibility of two types be two kinds of constraints?

On Saturday, June 20, 2020 at 4:48:07 PM UTC-4, Ian Lance Taylor wrote: > > On Sat, Jun 20, 2020 at 8:26 AM T L > > wrote: > > > > For example, if there is a builtin convertible(from, to) constraint, > > We can define a slice conversion function as >

[go-nuts] Re: [generics] Should convertibility and comparibility of two types be two kinds of constraints?

On Saturday, June 20, 2020 at 1:10:29 PM UTC-4, Bebop Leaf wrote: > > > > > And > > * should "embeddable" be one kind of constraints? > > Would you elaborate what do you mean by "embeddable"? > > As for the other 3, I agree it would be good to have them as constraints. > For example: type

[go-nuts] Re: [generics] Should convertibility and comparibility of two types be two kinds of constraints?

And * should "embeddable" be one kind of constraints? * should "has some specified fields" be one kind of constraints? On Saturday, June 20, 2020 at 11:26:08 AM UTC-4, T L wrote: > > For example, if there is a builtin convertible(from, to) constraint, > We can defin

[go-nuts] [generics] Should convertibility and comparibility of two types be two kinds of constraints?

For example, if there is a builtin convertible(from, to) constraint, We can define a slice conversion function as func Convert(type Ta, Tb converitble(Ta, Tb)) (avs []Ta, _Tb) (bvs []Tb) { bvs = make([]Tb, 0, len(avs) for _, v := range avs { bvs = append(bvs, Tb(v)) } return bvs

[go-nuts] Re: [generics] no methods with type parameters

The method set of a type should be stable. Generic methods make this impossible. On Saturday, June 20, 2020 at 9:31:53 AM UTC-4, Carsten Orthbandt wrote: > > Hi! > > First, thanks to the Go team for the hard work and the list populace for > an extremely low-noise list. Very much appreciated. >

Re: [go-nuts] Re: [generics] how to constraint a type must be a map or a slice?

> > Note that you are under no obligation to make use of a type-parameter if > you don't need it. > I don't very understand this. Can a slice value be used as the argument of the F function? > > On Sat, Jun 20, 2020 at 4:14 PM T L > > wrote: > >> I mean I don'

[go-nuts] Re: [generics] how to constraint a type must be a map or a slice?

)) // ... do some things } On Saturday, June 20, 2020 at 9:16:39 AM UTC-4, T L wrote: > > . > -- 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 g

[go-nuts] Re: [generics] how to constraint a type must be a map or a slice?

Or any map type with a specified key type but ignore the element type. On Saturday, June 20, 2020 at 9:16:39 AM UTC-4, T L wrote: > > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and st

[go-nuts] [generics] how to constraint a type must be a map or a slice?

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

[go-nuts] [generics] Is the draft design good to remove the code generation in the k8s project?

Such as: * non-reflected DeepCopy, Conversion * client-go/{informers,kubernetes/typed,listers} -- 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

Re: [go-nuts] [generics] some questions

On Thursday, June 18, 2020 at 8:01:22 AM UTC-4, Axel Wagner wrote: > > > > On Thu, Jun 18, 2020, 13:21 T L > wrote: > >> >> >> On Thursday, June 18, 2020 at 5:53:28 AM UTC-4, Axel Wagner wrote: >>> >>> >>> >>> On Thu, Jun

Re: [go-nuts] Re: [generics] some questions

So, it is really a bug. I will report it. On Thursday, June 18, 2020 at 8:17:22 AM UTC-4, Harald Weidner wrote: > > Hello, > > > But the following code also fails to compile, bug? > > > > package main > > > > type Int interface { > > type int > > } > > > > func Foo(type T Int) ([]T)

Re: [go-nuts] [generics] some questions

On Thursday, June 18, 2020 at 8:01:22 AM UTC-4, Axel Wagner wrote: > > > > On Thu, Jun 18, 2020, 13:21 T L > wrote: > >> >> >> On Thursday, June 18, 2020 at 5:53:28 AM UTC-4, Axel Wagner wrote: >>> >>> >>> >>> On Thu, Jun

[go-nuts] Re: [generics] some questions

It looks, in most cases, the current rules recommends the types shown in the constraint definition must be the elementary types. On Thursday, June 18, 2020 at 7:45:52 AM UTC-4, T L wrote: > It looks the generic type argument must share the underlying type of a > type in the constrain

[go-nuts] Re: [generics] some questions

Foo([]MyInt(nil)) } On Thursday, June 18, 2020 at 7:22:51 AM UTC-4, T L wrote: > > Another question, how to make the following code compile: > > package main > > type IntSlice interface { > type []int > } > > func Foo(type T IntSlice) (T) {} > > func mai

[go-nuts] Re: [generics] some questions

Another question, how to make the following code compile: package main type IntSlice interface { type []int } func Foo(type T IntSlice) (T) {} func main() { type MyInt int Foo([]int(nil)) Foo([]MyInt(nil)) // []MyInt does not satisfy IntSlice ([]MyInt not found in []int) } --

Re: [go-nuts] [generics] some questions

On Thursday, June 18, 2020 at 5:53:28 AM UTC-4, Axel Wagner wrote: > > > > On Thu, Jun 18, 2020, 11:28 T L > wrote: > >> How to declare a generic functions which converting a slice with type Ta >> to a slice with type Tb. Like >> func ConvertSlice(ty

[go-nuts] [generics] some questions

How to declare a generic functions which converting a slice with type Ta to a slice with type Tb. Like func ConvertSlice(type Ta, Tb constraint)(ins []Ta) []Tb {...} How to constraint a type parameter must be of an interface type? Is it possible to define generic unnamed types? If it is

Re: [go-nuts] What does the content about unsafe.Poiner in the compiler section in Go 1.15 release notes?

On Friday, June 12, 2020 at 1:33:32 PM UTC-4, Ian Lance Taylor wrote: > > On Fri, Jun 12, 2020 at 10:08 AM T L > > wrote: > > > > On Friday, June 12, 2020 at 1:02:30 PM UTC-4, Ian Lance Taylor wrote: > >> > >> On Fri, Jun 12, 2020 at 9:56 AM T L

Re: [go-nuts] What does the content about unsafe.Poiner in the compiler section in Go 1.15 release notes?

On Friday, June 12, 2020 at 1:02:30 PM UTC-4, Ian Lance Taylor wrote: > > On Fri, Jun 12, 2020 at 9:56 AM T L > > wrote: > > > > Is "uintptr(uintptr(ptr))" a typo? Or are there any other multiple > chained conversions examples? > > That is not a

Re: [go-nuts] What does the content about unsafe.Poiner in the compiler section in Go 1.15 release notes?

them so as to allow multiple chained > conversions. Now it doesn't. > > On Fri, Jun 12, 2020 at 2:28 PM T L > > wrote: > >> >> Package unsafe's safety rules >> <https://tip.golang.org/pkg/unsafe/#Pointer> allow converting an >> unsafe.Pointer i

[go-nuts] What does the content about unsafe.Poiner in the compiler section in Go 1.15 release notes?

Package unsafe's safety rules allow converting an unsafe.Pointer into uintptr when calling certain functions. Previously, in some cases, the compiler allowed multiple chained conversions (for example, syscall.Syscall(…, uintptr(uintptr(ptr)), …)).

[go-nuts] Re: When "go get" is run in neither a GOPATH directory nor a module-aware directory, should GOPROXY be used or not?

It looks the default mode in Go 1.14 is still GOPATH mode. So GOPROXY is ignored when "go get" run in neither a GOPATH directory nor a module-aware directory. On Tuesday, June 2, 2020 at 9:12:59 PM UTC-4, T L wrote: > . > -- You received this message because you are subscrib

[go-nuts] When "go get" is run in neither a GOPATH directory nor a module-aware directory, should GOPROXY be used or not?

. -- 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] A little weird thing in using finalizer

On Saturday, April 25, 2020 at 1:53:28 AM UTC-4, Brian Candler wrote: > > On Saturday, 25 April 2020 06:35:22 UTC+1, T L wrote: >> >> Why is each of the finalizers called twice? >> > > > Isn't it just printed once in main and once in finalizer? > https://p

Re: [go-nuts] A little weird thing in using finalizer

With time.Sleep, it always prints: > 31 > 37 > 47 > 47 > 37 > 31 > Why is each of the finalizers called twice? On Saturday, April 25, 2020 at 1:08:43 AM UTC-4, Ian Lance Taylor wrote: > > On Fri, Apr 24, 2020 at 9:30 PM T L > > wrote: > > > > The

[go-nuts] A little weird thing in using finalizer

The following program might print: 31 > 37 > 47 > 47 > 37 > 31 > or 31 > 37 > 47 > 47 > but with the highest possibility to print 31 > 37 > 47 > Is not normal? package main import ( "fmt" "math/rand" "runtime" "time" "unsafe" ) type Foo struct { x int a int }

Re: [go-nuts] Is the following funciton always safe to convert a string to a slice?

s not care about lexical types, only allocation types. On Tuesday, April 21, 2020 at 8:11:49 PM UTC-4, Ian Lance Taylor wrote: > > On Tue, Apr 21, 2020 at 6:49 AM T L > > wrote: > > > > func String2ByteSlice(str string) (bs []byte) { > > strHdr :

Re: [go-nuts] Re: Is the following funciton always safe to convert a string to a slice?

Many thanks. This is quite informative. On Wednesday, April 22, 2020 at 4:44:18 PM UTC-4, Ian Lance Taylor wrote: > > On Wed, Apr 22, 2020 at 7:08 AM T L > > wrote: > > > > I understand that, by the case 6 in the unsafe package docs, > > the second program

Re: [go-nuts] Re: Is the following funciton always safe to convert a string to a slice?

value assignments? On Wednesday, April 22, 2020 at 7:33:22 AM UTC-4, T L wrote: > > > > On Tuesday, April 21, 2020 at 8:13:17 PM UTC-4, Ian Lance Taylor wrote: >> >> On Tue, Apr 21, 2020 at 8:17 AM T L wrote: >> > >> > And is the runtime.KeepAli

Re: [go-nuts] Re: Is the following funciton always safe to convert a string to a slice?

On Tuesday, April 21, 2020 at 8:13:17 PM UTC-4, Ian Lance Taylor wrote: > > On Tue, Apr 21, 2020 at 8:17 AM T L > > wrote: > > > > And is the runtime.KeepAlive call in the following program essential to > keep the correctness? > > > > packag

[go-nuts] Re: Is the following funciton always safe to convert a string to a slice?

quot;, bs) // Google } On Tuesday, April 21, 2020 at 9:48:08 AM UTC-4, T L wrote: > > func String2ByteSlice(str string) (bs []byte) { > strHdr := (*reflect.StringHeader)(unsafe.Pointer()) > sliceHdr := (*reflect.SliceHeader)(unsafe.Pointer()) > > // Is it possi

[go-nuts] Is the following funciton always safe to convert a string to a slice?

func String2ByteSlice(str string) (bs []byte) { strHdr := (*reflect.StringHeader)(unsafe.Pointer()) sliceHdr := (*reflect.SliceHeader)(unsafe.Pointer()) // Is it possible that the str value is allocated on stack // and the stack grows at this moment, so the address value

[go-nuts] Some ideas about scope declarations and variable redeclarations.

Now, the qualified selector form is "aPkg.Exported". The form is the same as object selector, "aObj.Property". Sometimes, it is not very clear for code readers to recognize the first parts of such slectors is an import or an object. So, I think the C++ way "aPkg::Exported" is more readable. Let's

[go-nuts] Re: [golang-dev] Do slice element modification operations check whether or not the modified elements are allocated on immutable zones?

Glad to know this. Thanks for the info. On Thu, Jan 16, 2020 at 8:35 AM Ralph Corderoy wrote: > Hi Tapir, > > > Do slice element modification operations check whether or not the > > modified elements are allocated on immutable zones? > ... > > //var Golang = strings.Join([]string{"Go", "lang"},

[go-nuts] Re: About the change for default "-mod=vendor" in Go 1.14

On Thursday, January 9, 2020 at 3:38:56 AM UTC-5, T L wrote: > > Yes, when I change the "go 1.13" directive to "go 1.14", it suggests I > need to run 'go mod vendor' to sync. > After the sync, it works. Thanks for the help. > > So if the directive is 1.13,

[go-nuts] Re: About the change for default "-mod=vendor" in Go 1.14

Yes, when I change the "go 1.13" directive to "go 1.14", it suggests I need to run 'go mod vendor' to sync. After the sync, it works. Thanks for the help. So if the directive is 1.13, no default "-mod=vendor" compiler flag is set? And not any message is suggested? On Wednesday, January 8, 2020

[go-nuts] About the change for default "-mod=vendor" in Go 1.14

The release notes (https://tip.golang.org/doc/go1.14) says When the main module contains a top-level vendor directory and its go.mod file specifies go 1.14 or higher, the go command now defaults to -mod=vendor for operations that accept that flag. A new value for that flag, -mod=mod, causes

Re: [go-nuts] playground behaves different from local machine

approach here), it is > theoretically possible to make the program work today, using the > playground's support for multiple files: > https://play.golang.org/p/KLZR7NlVZNX > Though you probably also need to add some playground-specific code to set > environment variabl

Re: [go-nuts] playground behaves different from local machine

;(, looks the last comment doesn't appear in go-nuts. On Mon, Dec 23, 2019 at 9:37 AM T L wrote: > > > However, the playground has no GOROOT or build cache or anything > available: https://play.golang.org/p/RPGwtZSJSPQ > > But, isn't it ok to let the playground own a GOROOT?

[go-nuts] Re: playground behaves different from local machine

> by Axel Wagner: > However, the playground has no GOROOT or build cache or anything available: https://play.golang.org/p/RPGwtZSJSPQ But, isn't it ok to let the playground own a GOROOT? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

Re: [go-nuts] playground behaves different from local machine

run > locally, FWIW. That's the nature of a sandbox :) > > On Sun, Dec 22, 2019 at 5:58 PM T L wrote: > >> The code from the std go/types package parses the demo code well on local >> machine, but not in playground: >> >> https://play.golang.org/p/BlHHgdscaX

[go-nuts] playground behaves different from local machine

The code from the std go/types package parses the demo code well on local machine, but not in playground: https://play.golang.org/p/BlHHgdscaXj What is the cause? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group

[go-nuts] Some questions on using the "golang.org/x/tools/go/packages" package

The packages.Config.ParseFileParseFile docs (https://godoc.org/golang.org/x/tools/go/packages#Config) says // An application may supply a custom implementation of ParseFile // to change the effective file contents or the behavior of the parser, // or to modify the syntax tree. For

Re: [go-nuts] Re: An old problem: lack of priority select cases

On Saturday, October 5, 2019 at 6:28:37 AM UTC-4, ohir wrote: > > On Fri, 4 Oct 2019 15:15:30 -0700 (PDT) > T L > wrote: > > > > If your out <-v must be dependent of ctx.Done not being ready you > > > must resolve this dependency by other means. Eg. by

Re: [go-nuts] Re: An old problem: lack of priority select cases

> Please, drop it. You don't know what you're talking about. I've been amazed at how patient everyone has been. I think it's time to be more blunt in pointing out you don't understand concurrency and independent events. Maybe. But you don't know I'm talking about for sure. -- You received

Re: [go-nuts] Re: An old problem: lack of priority select cases

On Friday, October 4, 2019 at 5:40:08 PM UTC-4, ohir wrote: > > On Fri, 4 Oct 2019 13:52:19 -0700 (PDT) > T L > wrote: > > > One priority-order select block is not only cleaner than two > random-order > > select blocks, but also more efficient. > > It i

Re: [go-nuts] Re: An old problem: lack of priority select cases

latency. > Yes, select case priority tries to always select one case of the two cases when both the two cases are available. Without this feature, to achieve this goal, we often need two select blocks (sorry, I mis-typed select block as select case in my last comment). One priority-order select

Re: [go-nuts] Re: An old problem: lack of priority select cases

e to deduce two select cases to one select case in coding in many scenarios. This often leads to cleaner code, and sometimes can avoid the harm caused by missing an essential try-receive select case. > -Original Message- > From: T L > Sent: Oct 4, 2019 2:44 PM > To: golang-n

Re: [go-nuts] Re: An old problem: lack of priority select cases

deduce two select cases to one select case in coding in many scenarios. This often leads to cleaner code, avoid can avoid the harm caused by missing a try-receive select case. > -Original Message- > From: T L > Sent: Oct 4, 2019 2:44 PM > To: golang-nuts > Subject:

Re: [go-nuts] Re: An old problem: lack of priority select cases

BTW, I don't understand what you said. Could you elaborate more? > On Oct 4, 2019, at 1:46 PM, T L > wrote: > >  > I just found an example in the "context" package docs: > > // // Stream generates values with DoSomething and sends them to out > // //

[go-nuts] Re: An old problem: lack of priority select cases

On Friday, October 4, 2019 at 2:46:36 PM UTC-4, T L wrote: > > I just found an example in the "context" package docs: > > // // Stream generates values with DoSomething and sends them to out > // // until DoSomething returns an error or ctx.Done is closed.

[go-nuts] Re: An old problem: lack of priority select cases

return ctx.Err() // case out <- v: // } // } // } It looks the send "out <- v" still has a possibility to be executed, even if "ctx.Done()" is closed. But if Go supports select case priority, then this will never happen. On Wednesday,

Re: [go-nuts] A confusion on the cgo document.

Got it. Thanks, Ian. On Mon, Sep 30, 2019 at 9:10 PM Ian Lance Taylor wrote: > On Mon, Sep 30, 2019 at 1:01 AM T L wrote: > > > > https://golang.org/cmd/cgo/#hdr-Passing_pointers > > > > When passing a pointer to a field in a struct, the Go memory in questi

[go-nuts] A confusion on the cgo document.

https://golang.org/cmd/cgo/#hdr-Passing_pointers When passing a pointer to a field in a struct, the Go memory in question is the memory occupied by the field, not the entire struct. When passing a pointer to an element in an array or slice, the Go memory in question is the entire array or the

Re: [go-nuts] Go playfield has no time limit now?

ess >> loop too) >> What changed, I guess, is that output produced before the process got cut >> of is now actually served. >> >> On Wed, Sep 25, 2019 at 1:29 PM T L > >> wrote: >> >>> For example: https://play.golang.org/p/YhWgTpzGj0T >>>

[go-nuts] Go playfield has no time limit now?

For example: https://play.golang.org/p/YhWgTpzGj0T -- 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

[go-nuts] Re: request for feedback: another websocket server implementation

Just for reference. Here are other Go websocket implementations: * Gorilla WebSocket https://github.com/gorilla/websocket * https://github.com/nhooyr/websocket * https://github.com/gobwas/ws * x/net/websocket https://godoc.org/golang.org/x/net/websocket On Tuesday, September 17, 2019 at 6:29:08

Re: [go-nuts] Who can explain more on the "upgrade" module version selector?

On Sunday, September 15, 2019 at 12:35:27 PM UTC-4, Axel Wagner wrote: > > On Sun, Sep 15, 2019 at 6:11 PM T L > > wrote: > >> Do you mean if there is already a require line in the go.mod file, >> which requires a non-formal tagged version, >> then "go get

Re: [go-nuts] Who can explain more on the "upgrade" module version selector?

atest" will rollback the require to the latest formal tagged version, but "go get ...@upgrade" will not? > > On Sat, Sep 14, 2019 at 10:35 AM T L > > wrote: > >> The doc https://golang.org/cmd/go/#hdr-Module_queries says: >> >> The string &q

[go-nuts] Who can explain more on the "upgrade" module version selector?

The doc https://golang.org/cmd/go/#hdr-Module_queries says: The string "upgrade" is like "latest", but if the module is currently > required at a later version than the version "latest" would select (for > example, a newer pre-release version), "upgrade" will select the later > version

Re: [go-nuts] Re: If v2.x.y+incompatible exists, then getting the modules based v3 version will always fail?

think output message is not very clear, it is even some misleading. > > On Fri, Sep 13, 2019 at 12:53 PM T L > > wrote: > > > > I really don't get how modules are got. > > I create another repo with all versions are module based, but it still > fails on getting

[go-nuts] Re: If v2.x.y+incompatible exists, then getting the modules based v3 version will always fail?

PM UTC-4, T L wrote: > > For example, > > $ $ go get github.com/go101/mod_versions/v3@latest > go: finding github.com/go101/mod_versions/v3 v3.1.0 > go get github.com/go101/mod_versions/v3@latest: module > github.com/go101/mod_versions@latest (v2.0.0+incompatible) found, bu

[go-nuts] If v2.x.y+incompatible exists, then getting the modules based v3 version will always fail?

For example, $ $ go get github.com/go101/mod_versions/v3@latest go: finding github.com/go101/mod_versions/v3 v3.1.0 go get github.com/go101/mod_versions/v3@latest: module github.com/go101/mod_versions@latest (v2.0.0+incompatible) found, but does not contain package

Re: [go-nuts] What happens if the hash retrieved from sumdb and the one in go.sum file of the main module are different?

On Thursday, September 12, 2019 at 11:58:30 AM UTC-4, T L wrote: > > > > On Wednesday, September 11, 2019 at 5:33:02 PM UTC-4, Ian Lance Taylor > wrote: >> >> The go tool reports a checksum mismatch error. >> >> Ian >> > > "go help

Re: [go-nuts] An old problem: lack of priority select cases

On Thursday, September 12, 2019 at 11:22:35 AM UTC-4, trishc...@gmail.com wrote: > > Why not just set up priority blockers against the one What does priority blockers mean? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from

Re: [go-nuts] What happens if the hash retrieved from sumdb and the one in go.sum file of the main module are different?

On Wednesday, September 11, 2019 at 5:33:02 PM UTC-4, Ian Lance Taylor wrote: > > The go tool reports a checksum mismatch error. > > Ian > "go help module-auth" says If a downloaded module is not yet included in go.sum and it is a publicly available module, the go command consults the Go

[go-nuts] What happens if the hash retrieved from sumdb and the one in go.sum file of the main module are different?

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

[go-nuts] Re: Is there a way to use the pakckages under vendor folder and from module cache?

s currently. It would be great if there is a simpler way to support both always-on vendor and cached vendor at the same time. On Tuesday, September 10, 2019 at 12:30:56 PM UTC-4, t hepudds wrote: > > Hello T L, > > I think I might not fully understand the exact scenario, but one thing > s

[go-nuts] Re: Is there a way to use the pakckages under vendor folder and from module cache?

have higher look-up priorities than the packages under "vendor" folder. On Tuesday, September 10, 2019 at 9:03:52 AM UTC-4, T L wrote: > > I mean "to use the pakckages under vendor folder and from module cache at > the same time". > > I have one question, is it be

[go-nuts] Re: Is there a way to use the pakckages under vendor folder and from module cache?

build -use-local-module-cache" can use the packages in the old "vendor" folder and the "module-cache" folder? On Tuesday, September 10, 2019 at 8:59:28 AM UTC-4, T L wrote: > > I maintain an private old Go project, which depends many many old packages. > Before the

[go-nuts] Is there a way to use the pakckages under vendor folder and from module cache?

I maintain an private old Go project, which depends many many old packages. Before the module mode, I put all these dependency packages under the vendor folder. In the developing process, from time to time, I modified some of dependency packages. Meanwhile, I plan to migrate the project to

Re: [go-nuts] Re: An old problem: lack of priority select cases

losing. Pretty simple. >>>>> >>>>> Just encapsulate it all in a MultiWriterChannel struct - generics >>>>> would help here :) >>>>> >>>>> -Original Message- >>>>> From: Leo Lara >>>&g

[go-nuts] Re: Closed channel vs nil channel when writing

On Sunday, September 1, 2019 at 12:03:58 PM UTC-4, clement auger wrote: > > hi, > > I am looking for further details and explanations about the various > behaviors > associated with closed Vs nil channels. > > I already read >

[go-nuts] Re: By passing go type check when performing bitwise operator

On Sunday, September 1, 2019 at 2:03:37 PM UTC-4, Albert Tedja wrote: > > I am trying to perform some bitwise operators, but Go is not letting me > because the mask is an uint and the values are int. Setting the mask to int > will break the code since I am shifting bits right and left and

Re: [go-nuts] An old problem: lack of priority select cases

> It would be great if you can share the library here. I'm surely interested. And I think many other gophers also have interests. :) > > On Sunday, September 1, 2019 at 3:02:52 AM UTC-7, T L wrote: >> >> >> >> On Sunday, September 1, 2019 at 4:35:10 AM UTC-4, rog wro

Re: [go-nuts] An old problem: lack of priority select cases

etty hard to have what I stated not be the case. > > On Sep 1, 2019, at 9:46 AM, T L > wrote: > > This is not true, at least no Go official documentation admits this. > > On Sunday, September 1, 2019 at 7:42:38 AM UTC-4, Robert Engels wrote: >> >> That is incorrect. T

Re: [go-nuts] An old problem: lack of priority select cases

ted cache > lines the atomic load will pick it up. > > On Aug 31, 2019, at 10:55 PM, T L > wrote: > > > > On Saturday, August 31, 2019 at 9:49:56 PM UTC-4, Robert Engels wrote: >> >> Yes, that is why the original code did not use a lock on the read but the >&g

Re: [go-nuts] An old problem: lack of priority select cases

On Sunday, September 1, 2019 at 4:35:10 AM UTC-4, rog wrote: > > > > On Sat, 31 Aug 2019 at 10:02, T L > wrote: > >> >> >> On Saturday, August 31, 2019 at 4:04:29 AM UTC-4, T L wrote: >>> >>> >>> >>> On Saturday, August 31,

Re: [go-nuts] An old problem: lack of priority select cases

ound > You mean this one: https://play.golang.org/p/JRSEPU3Uf17 ? No no, it is not a good ideas to use mutex in write but atomic in read to avoid concurrently accessing the same value. > > On Aug 31, 2019, at 7:50 AM, T L > wrote: > > > > On Saturday, August 31, 201

Re: [go-nuts] An old problem: lack of priority select cases

ader running. Unless the > channel is closed and then the writer will panic. > > The code I provided is valid. > In fact, if I comment out the write instead read part, the code will also crash on all goroutines are blocked. > > On Aug 31, 2019, at 2:40 AM, T L > wrote: > &

Re: [go-nuts] An old problem: lack of priority select cases

On Saturday, August 31, 2019 at 4:04:29 AM UTC-4, T L wrote: > > > > On Saturday, August 31, 2019 at 2:32:26 AM UTC-4, rog wrote: >> >> The reason you're wanting priority select is because you are shutting >> down the data channel preemptively, but you can wait f

Re: [go-nuts] An old problem: lack of priority select cases

.org/p/qSWluYy4ifl > > Your solution is clever. The Close method can be called multiple time safely. Is there such a beautiful solution for multiple senders? > > On Wed, 28 Aug 2019 at 18:06, T L > wrote: > >> The old thread: >> https://groups.google.com/forum/#

Re: [go-nuts] An old problem: lack of priority select cases

sleeping (not just blocked), so you need to run > it locally. > My fault. But it doesn't matter, for the Read method is never called (I commented it off). It also crash locally for all goroutines are blocked. > -Original Message- > From: T L > Sent: Aug 30, 2019 12:05

Re: [go-nuts] An old problem: lack of priority select cases

losed. > https://play.golang.org/p/pcwIu2w8ZRb All go routines are blocked in the modified version. > -Original Message- > From: T L > Sent: Aug 30, 2019 11:13 AM > To: golang-nuts > Subject: Re: [go-nuts] An old problem: lack of priority select cases > > > > On

Re: [go-nuts] An old problem: lack of priority select cases

the subsequent readers > will queue behind the "writer = closer". > How about unknown/random number of senders and readers? > > -Original Message- > From: T L > Sent: Aug 30, 2019 8:50 AM > To: golang-nuts > Subject: Re: [go-nuts] An old proble

Re: [go-nuts] An old problem: lack of priority select cases

ds Closed() and > Read() and when I refactored I forgot to add the Read lock to the Read(). > That's why you always have code reviews... > > -Original Message- > From: T L > Sent: Aug 29, 2019 6:25 PM > To: golang-nuts > Subject: Re: [go-nuts] An old probl

Re: [go-nuts] An old problem: lack of priority select cases

gt; A better solution is to wrap the writes using a RWLock, grab the read >>>>> lock for writing, and the Write lock for closing. Pretty simple. >>>>> >>>>> Just encapsulate it all in a MultiWriterChannel struct - generics >>>>> would help he

  1   2   3   4   5   6   >