[go-nuts] Re: TLS negotiation bug in go1.21.4?

hello, curious if you were able to resolve the issue by downgrading golang? im having the exact same issue as you causing TLS handshakes to fail On Thursday, January 11, 2024 at 8:06:16 AM UTC+8 Andrew Athan wrote: > I tried go1.21.6 and see the same behavior. I'm going to try to backport >

[go-nuts] Re: TLS negotiation bug in go1.21.4?

hello, curious if you were able to resolve the issue by downgrading golang? I am having the exact same issue as you with cpu blowing up at crypto/internal/bigmod.(*Nat).montgomeryMul causing TLS handshakes to fail On Thursday, January 11, 2024 at 8:06:16 AM UTC+8 Andrew Athan wrote: > I tried

[go-nuts] Re: TLS negotiation bug in go1.21.4?

I tried go1.21.6 and see the same behavior. I'm going to try to backport the project to go1.18 to see what happens. On Wednesday, January 10, 2024 at 3:51:16 PM UTC-8 Andrew Athan wrote: > As you can see in the below output from pprof, the golang TLS > implementation seems to be in some kind

Re: [go-nuts] Re: [rfc] build bug in type abstraction?

Hi Brian, Thanks for the review. Your basic conclusion matches mine, that the ./main/main.go:46 and ./types.go are proven in the "go run" case, and disproven in the "go build" case. Best, John On Wed, Aug 16, 2023 at 9:58 AM Brian Candler wrote: > On Wednesday, 16 August 2023 at 14:05:49

[go-nuts] Re: [rfc] build bug in type abstraction?

On Wednesday, 16 August 2023 at 14:05:49 UTC+1 John Pritchard wrote: I have a disparity between "go run" [ https://go.dev/play/p/5mr5M0luZ9k?v=goprev] and "go build" [https://github.com/syntelos/go-type-abstraction/tree/third]. Using go version 1.21.0. I don't quite understand where "go

[go-nuts] Re: [rfc] build bug in type abstraction?

A few things: * As illustrated by the output in your README, it appears your "make list" command is only compiling "main/main.go", rather than both "main/main.go" and "main/run.go" * There can only be one main function per main package in Go, so I'm not sure how main/run.go and main/main.go

[go-nuts] Re: Maybe a Bug? The Go compiler stores a stack pointer into a global object

Thanks for the relpy. I have opened an issue on github: https://github.com/golang/go/issues/61730 On Thursday, 3 August 2023 at 17:49:25 UTC+8 Michael Knyszek wrote: > That line (the full sentence is "The garbage collector now includes > non-heap sources of garbage collector work (e.g., stack

[go-nuts] Re: Maybe a Bug? The Go compiler stores a stack pointer into a global object

That line (the full sentence is "The garbage collector now includes non-heap sources of garbage collector work (e.g., stack scanning) when determining how frequently to run.") is unrelated. It only refers to a change in accounting for what gets included in the GOGC calculation, not a change in

[go-nuts] Re: Maybe a Bug? The Go compiler stores a stack pointer into a global object

I notice that Go1.17.7 still allocates the array on heap by calling newobject while Go1.18 allocates the array on stack. I also notice that in the release note of Go1.18 that "The garbage collector now includes non-heap sources of garbage collector work". Does the GC in 1.18 and following

[go-nuts] Re: Maybe a Bug? The Go compiler stores a stack pointer into a global object

Yes, that looks very, very wrong. It looks like this issue goes back to at least 1.16. If you can open an issue at https://github.com/golang/go/issues we can investigate. On Wednesday, August 2, 2023 at 10:03:31 AM UTC-7 Jinbao Chen wrote: > I use go1.20.5 to compile the following code. >

[go-nuts] is this a bug in "go fmt"?

Original code: $ cat production.go //go:build production // +build production // +build linux << Notice This Line as my production code is only available on Linux package main const ( isProductionCode = true isDebugCode = false ) $ go fmt production.go production.go $ cat

[go-nuts] Is this a bug ?

https://groups.google.com/g/golang-nuts package main import ( "fmt" ) func main() { const aa int = 0 var a int fmt.Println(float64(1

[go-nuts] Is there a bug in the command "go list -deps -json ./..."?

I checked out the kubernetes project at tag v1.20.4. Then run "go list -deps -json ./... > json,txt" in the project root. In the produced json.txt file, I notice that the module path for two packages look not right. The path of a package should be prefixed with its module path. But the two don't.

Re: [go-nuts] Ambiguous Method Promotion Bug?

"and so does zz.X.Fun", of course. On Tue, Nov 17, 2020 at 10:14 PM Axel Wagner wrote: > Hi, > > the relevant spec section is https://golang.org/ref/spec#Selectors > > A selector f may denote a field or method f of a type T, or it may refer >> to a field or method f of a nested embedded field

Re: [go-nuts] Ambiguous Method Promotion Bug?

Hi, the relevant spec section is https://golang.org/ref/spec#Selectors A selector f may denote a field or method f of a type T, or it may refer to > a field or method f of a nested embedded field of T. The number of embedded > fields traversed to reach f is called its depth in T. The depth of a

[go-nuts] Ambiguous Method Promotion Bug?

Here is a playground doc that demonstrates what seems to be strange behavior regarding promotion of methods. https://play.golang.org/p/R9M1lAOd9CA It seems that I can generate a struct a have an ambiguous method by adding a level of indirection in struct definitions. Or there's something in

Re: [go-nuts] Is this a bug?

There's a Go issue which is relevant here: https://github.com/golang/go/issues/8082 On Sat, 25 May 2019 at 04:54, Dan Kortschak wrote: > The interfaces that define the contracts should come from a third > package/source. The issue that I suspect you are hitting is that type > identity for

Re: [go-nuts] Is this a bug?

The interfaces that define the contracts should come from a third package/source. The issue that I suspect you are hitting is that type identity for interface types is based on the name, not the method set. This means that, for example with your code below a function PrintB(StringerB) and another

Re: [go-nuts] Is this a bug?

The posted diagram isn't correct. Updated the diagram with the new one. [image: go1.png] On Saturday, May 25, 2019 at 10:38:42 AM UTC+7, Henry wrote: > > Thanks for the reply. > > Is there any specific use case that this intended behavior is supposed to > solve? It appears to me that it is

Re: [go-nuts] Is this a bug?

On Fri, May 24, 2019 at 10:55 AM Henry wrote: > > Hi, > > I stumbled across this weird behavior and I wonder whether this is a bug. > Here is the simplified version of the problem (Playground link > https://play.golang.org/p/mch6NQdTpr5): I believe this is working as intended because a type

Re: [go-nuts] Is this a bug?

It's not a bug, FormatterA and FormatterB method has different signatures, they are not identical, one wants Format(StringerA) other Format(StringerB), thus your Format type only implements FormatterA but Print wants a FormatterB. -- You received this message because you are subscribed to the

[go-nuts] Is this a bug?

Hi, I stumbled across this weird behavior and I wonder whether this is a bug. Here is the simplified version of the problem (Playground link https://play.golang.org/p/mch6NQdTpr5): package main import ( "fmt" ) func main() { str := MyString("World") var formatter Format Print(formatter,

Re: [go-nuts] golang.org/x/oauth2 bug???

On Fri, Dec 7, 2018 at 6:46 AM Harald Fuchs wrote: > > I think there's something fishy about clientcredentials. Having > trouble with client_secrets containig special chars, first I modified > clientcredentials_test.go like this: > > > func TestTokenRequest(t *testing.T) { > > cfg := newConf("")

[go-nuts] golang.org/x/oauth2 bug???

I think there's something fishy about clientcredentials. Having trouble with client_secrets containig special chars, first I modified clientcredentials_test.go like this: > func TestTokenRequest(t *testing.T) { > cfg := newConf("") > data := fmt.Sprintf("%s:%s", cfg.ClientID, cfg.ClientSecret) >

[go-nuts] gob limitation or bug?

package main import ( "bytes" "encoding/gob" "fmt" ) var data = bytes.NewBuffer(nil) var buff = bytes.NewBuffer(nil) var encoder = gob.NewEncoder(data) var decoder = gob.NewDecoder(buff) func main() { encode() decode() decode() } func encode() { n := [][]int32{[]int32{1},

[go-nuts] 【go-nuts] liteide x35.2 released, bug fixed.

Hi, all. LiteIDE X35.2 released! This version fixed jump source bug. Optimization editor/bookmark/golangdoc plugins. * LiteIDE Home         * LiteIDE Source code         * Release downloads        

Re: [go-nuts] an "append" use, bug or intended design?

On Saturday, March 17, 2018 at 1:54:17 AM UTC-4, T L wrote: > > > > On Friday, March 16, 2018 at 3:31:23 PM UTC-4, Axel Wagner wrote: >> >> >> >> On Fri, Mar 16, 2018 at 8:20 PM, T L wrote: >> >>> >>> >>> On Friday, March 16, 2018 at 2:57:48 PM UTC-4, Jan Mercl wrote:

Re: [go-nuts] an "append" use, bug or intended design?

On Friday, March 16, 2018 at 3:31:23 PM UTC-4, Axel Wagner wrote: > > > > On Fri, Mar 16, 2018 at 8:20 PM, T L > wrote: > >> >> >> On Friday, March 16, 2018 at 2:57:48 PM UTC-4, Jan Mercl wrote: >>> >>> On Fri, Mar 16, 2018 at 7:40 PM T L wrote: >>> >>>

Re: [go-nuts] an "append" use, bug or intended design?

On Fri, Mar 16, 2018 at 8:20 PM, T L wrote: > > > On Friday, March 16, 2018 at 2:57:48 PM UTC-4, Jan Mercl wrote: >> >> On Fri, Mar 16, 2018 at 7:40 PM T L wrote: >> >> >> > I feel the second append call should be also valid. >> >> Works as intended: T is

Re: [go-nuts] an "append" use, bug or intended design?

On Friday, March 16, 2018 at 2:57:48 PM UTC-4, Jan Mercl wrote: > > On Fri, Mar 16, 2018 at 7:40 PM T L > wrote: > > > > I feel the second append call should be also valid. > > Works as intended: T is not struct{} > > If desired, it can become that:

Re: [go-nuts] an "append" use, bug or intended design?

On Fri, Mar 16, 2018 at 7:40 PM T L wrote: > I feel the second append call should be also valid. Works as intended: T is not struct{} If desired, it can become that: https://play.golang.org/p/nY-BB3t0IAw -- -j -- You received this message because you are subscribed

[go-nuts] an "append" use, bug or intended design?

package main import "fmt" type T struct{} func main() { s := []struct{}{ struct{}{}, } var x []T x = append(x, s[0]) // valid x = append(x, s...) // invalid fmt.Println(x) } I feel the second append call should be also valid. -- You received this message

Re: [go-nuts] Is this a bug?

The point to remember is that each value of a concrete type has exactly that one concrete type, while each value of an interface type has exactly one interface type and one concrete type. It is also important to note that there is a distinction between "assignability" and "type-assertiblity". *

Re: [go-nuts] Is this a bug?

On Sun, 25 Feb 2018 09:25:42 + Jan Mercl <0xj...@gmail.com> wrote: Jan Mercl writes: > --f4f5e808e63ceebaa7056605faf5 > Content-Type: text/plain; charset="UTF-8" > > On Sun, Feb 25, 2018 at 10:23 AM Bakul Shah wrote: > > > Why not case T2? > > It does match T2 as well.

Re: [go-nuts] Is this a bug?

On Sun, Feb 25, 2018 at 10:23 AM Bakul Shah wrote: > Why not case T2? It does match T2 as well. The order of cases of the type switch maters: https://play.golang.org/p/nb28xHQP7oU -- -j -- You received this message because you are subscribed to the Google Groups

Re: [go-nuts] Is this a bug?

On Sun, 25 Feb 2018 01:01:08 -0800 Dave Cheney wrote: Dave Cheney writes: > --=_Part_12529_340231507.1519549268925 > Content-Type: text/plain; charset="UTF-8" > > Type C conforms to the T1 interface? > > What did you expect? C conforms to both T1 and T2. var x2 T2

[go-nuts] Is this a bug?

Type C conforms to the T1 interface? What did you expect? -- 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

[go-nuts] Is this a bug?

https://play.golang.org/p/IMWd3cvgfsU // also replicated below package main import ( "fmt" ) type ( T1 interface{ f1()int; f2()int } T2 interface{ f2()int; f3()int } ) type C int func (c C)f1()int {return 1} func (c C)f2()int {return 2} func (c C)f3()int {return 3}

Re: [go-nuts] Re: Float multiplication bug?

This question is already answered, but i was on a plane and added a bit to the printing and the comments. in case anyone ever refers to this thread in the future, this is the better version of the program to run: https://play.golang.org/p/EK0XMnMUKwv On Fri, Feb 23, 2018 at 8:06 AM, Michael Jones

Re: [go-nuts] Re: Float multiplication bug?

One subtle thing is the difference between an ideal number, its floating-point representation, and its printed form. On Fri, Feb 23, 2018 at 5:46 AM, wrote: > Thanks guys. That's very helpful. I forgot that what I saw (and re-used) > as the "height" was not precise

[go-nuts] Re: Float multiplication bug?

Thanks guys. That's very helpful. I forgot that what I saw (and re-used) as the "height" was not precise enough to make it comparable. On Thursday, February 22, 2018 at 3:33:38 PM UTC-5, Steve Bagwell wrote: > > > Hello Everyone, > > This looks like a Golang bug to me. What do you all think?

Re: [go-nuts] Is this a bug or am I missing something?

When you append to a slice with the append function, it just assigns the value to the len.th slot and increments len. This is only possible, if the backing array is big enough. This backing array capacity is the slice's capacity, retrieved by cap. If the capacity is not enough, a new, bigger

Re: [go-nuts] Is this a bug or am I missing something?

Hi Jesse Thank you very much. I guess that happens when you come to Go with a PHP background. I still have one question, why does it happen always on that iteration? Not the previous iterations? On Tuesday, December 19, 2017 at 4:32:09 PM UTC+11, Jesse McNelis wrote: > > On Tue, Dec 19, 2017

Re: [go-nuts] Is this a bug or am I missing something?

On Tue, Dec 19, 2017 at 4:10 PM, Sasan Rose wrote: > Hi Jess > > Apologies for my bad example. Please kindly see my reply to Dave's post. > Thanks I fixed your example so that the slice called 'combination' isn't shared with every slice in every iteration of the loop.

Re: [go-nuts] Is this a bug or am I missing something?

Hi Jess Apologies for my bad example. Please kindly see my reply to Dave's post. Thanks On Tuesday, December 19, 2017 at 2:43:50 PM UTC+11, Jesse McNelis wrote: > > On Tue, Dec 19, 2017 at 8:54 AM, Sasan Rose > wrote: > > Please take a look at

Re: [go-nuts] Is this a bug or am I missing something?

On Tue, Dec 19, 2017 at 8:54 AM, Sasan Rose wrote: > Please take a look at https://play.golang.org/p/BL4LUGk-lH solutionNew = make([]int, 0) solutionNew = append(solution, 2) Is a strange thing to do, you create a new slice using make([]int, 0) and then never use it.

[go-nuts] Is this a bug or am I missing something?

Please take a look at https://play.golang.org/p/BL4LUGk-lH I think I know how slices work (The 3-word structure). I tried to do my homework. But still I think I'm missing something here or it's really a bug. So In my code as you can see I'm appending to an slice (a variable called slice

[go-nuts] go test/flag.NewFlagSet bug?

when I run the minimal program below it errors about NOT knowing -data flag: go test -v -args -data=x flag provided but not defined: -data Usage of /tmp/go-build454762170/github.com/phcurtis/flagexp/_test/flagexp.test: -test.bench regexp blah blah, if you change nfs=false ... and then

[go-nuts] Re: Possible optimization bug in go1.8?

On Monday, 8 May 2017 15:51:00 UTC+2, Shabinesh Sivaraj wrote: > > func xrand() int { > r := rand.New(rand.NewSource(99)) > return r.Int() > } > What am I missing here? Could it be a bug? > Not a bug. r := rand.New(rand.NewSource(99)) creates a new random number generator seeded to a

[go-nuts] Is there a bug in path.Dir?

In windows platform, path.Dir and path.Base can't get the correct result. The test code is like this: func main() { filename := "F:\\Test\\conf\\rkc1" i := strings.LastIndex(filename, string(filepath.Separator)) fmt.Println("dir1:", string(filename[:i+1]))