Re: [go-nuts] detecting cyclic references

The question was about detecting cyclic references. For that, the `l[0] = l` case is enough. On Wed, Nov 11, 2020 at 2:31 AM jake...@gmail.com wrote: > FYI, that does detect the simple case of l[0] = l, but not more > complicated circular cases like l[1] = l[1:] > > On Tuesday, November 10,

Re: [go-nuts] Proposal: New keyword returnif (resolves error handling)

On Wed, Nov 11, 2020 at 2:43 AM Jeremy French wrote: > I certainly can't speak for the whole community, but for me, the key word > here is verbosity. I don't care (too much) whether it's technically a > statement or an expression or a macro. What I care about is signal to noise > ratio in my

Re: [go-nuts] Re: use same for/range code on a hash map but it has different result

On Tue, 2020-11-10 at 22:17 -0800, Kurtis Rader wrote: > Jeebus. H. Christ! Yes, you can "safely" mutate a map while iterating > over it. In as much as doing so will not result in a panic; although, > I'm not convinced that is true. The point of the O.P. is that they > expect the map mutation to

Re: [go-nuts] Re: My app hangs up at some point in net/http/h2_bundle.go. What is the better way to debug?

OS: Manjaro 20.2 Nibia Kernel: x86_64 Linux 5.4.74-1-MANJARO ср, 11 нояб. 2020 г. в 12:59, Kurtis Rader : > On Tue, Nov 10, 2020 at 9:39 PM Denis Telyukh > wrote: > >> 1. Got some stuck requests >> 2. netstat -atp >> tcp 25 0 dionysius-pc:52340 server-52-85-47-1:https >>

Re: [go-nuts] Re: use same for/range code on a hash map but it has different result

On Tue, Nov 10, 2020 at 10:03 PM 'Dan Kortschak' via golang-nuts < golang-nuts@googlegroups.com> wrote: > On Tue, 2020-11-10 at 20:28 -0800, 'Kilos' via golang-nuts wrote: > > You cannot safely mutate a Go map while iterating over it with the > > `range` operator. > > This is not true, depending

Re: [go-nuts] Re: use same for/range code on a hash map but it has different result

On Wed, 2020-11-11 at 06:02 +, 'Dan Kortschak' via golang-nuts wrote: > So long as you take into account these caveats, mutating a map during > a range will not corrupt the map or other data structure, and will > cause your application to crash. s/will cause/will not cause/ -- You received

Re: [go-nuts] Re: use same for/range code on a hash map but it has different result

On Tue, 2020-11-10 at 20:28 -0800, 'Kilos' via golang-nuts wrote: > You cannot safely mutate a Go map while iterating over it with the > `range` operator. This is not true, depending on your definition of "safely". See https://golang.org/ref/spec#For_statements "For statements with range

Re: [go-nuts] Re: My app hangs up at some point in net/http/h2_bundle.go. What is the better way to debug?

On Tue, Nov 10, 2020 at 9:39 PM Denis Telyukh wrote: > 1. Got some stuck requests > 2. netstat -atp > tcp 25 0 dionysius-pc:52340 server-52-85-47-1:https > CLOSE_WAIT 1364/brave --type=u > tcp 25 0 dionysius-pc:40296 server-13-33-240-:https > CLOSE_WAIT

Re: [go-nuts] Re: My app hangs up at some point in net/http/h2_bundle.go. What is the better way to debug?

1. Got some stuck requests 2. netstat -atp tcp 25 0 dionysius-pc:52340 server-52-85-47-1:https CLOSE_WAIT 1364/brave --type=u tcp 25 0 dionysius-pc:40296 server-13-33-240-:https CLOSE_WAIT 1364/brave --type=u 3. A few second later netstat doesn't show any

Re: [go-nuts] Re: use same for/range code on a hash map but it has different result

For Kurtis: Thank you, I will remember this: You cannot safely mutate a Go map while iterating over it with the `range` operator. I will not do this when programming, but when I learned about this, then I want to know the underlying reason. And now, I have known. 在2020年11月11日星期三 UTC+8

Re: [go-nuts] Re: use same for/range code on a hash map but it has different result

On Tue, Nov 10, 2020 at 8:12 PM 'Kilos' via golang-nuts < golang-nuts@googlegroups.com> wrote: > For Kurtis: > I know the map will choose random hash seed to init itself, and the > iterator will also choose random order to iterate map. > And I know it is a bad idea to add or delete a key when

Re: [go-nuts] Re: use same for/range code on a hash map but it has different result

For Kurtis: If my idea is correct, then my question has been solved, thank you for replying. 在2020年11月11日星期三 UTC+8 下午12:16:26 写道： > On Tue, Nov 10, 2020 at 7:57 PM 'Kilos' via golang-nuts < > golan...@googlegroups.com> wrote: > >> For Dan: >> I have an idea that the cause is in the runtime

Re: [go-nuts] Re: use same for/range code on a hash map but it has different result

On Tue, Nov 10, 2020 at 7:57 PM 'Kilos' via golang-nuts < golang-nuts@googlegroups.com> wrote: > For Dan: > I have an idea that the cause is in the runtime function mapiternext. > The runtime calls mapiternext function to choose next bucket to iterate by > index, > if we put a key-value into a

Re: [go-nuts] Re: use same for/range code on a hash map but it has different result

For Kurtis: I know the map will choose random hash seed to init itself, and the iterator will also choose random order to iterate map. And I know it is a bad idea to add or delete a key when iterating a map, but I want to know what causes the inpredictable result, not the key's iterating order,

Re: [go-nuts] Re: use same for/range code on a hash map but it has different result

For Dan: I have an idea that the cause is in the runtime function mapiternext. The runtime calls mapiternext function to choose next bucket to iterate by index, if we put a key-value into a bucket which already be iterated, then the for-range will not iterate it again, so the new key-value will

Re: [go-nuts] Re: use same for/range code on a hash map but it has different result

On Tue, Nov 10, 2020 at 7:09 PM 'Kilos' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Thanks for reply, but I want to know the underlying reason about it, I > think the reason is in how the runtime functions works. > And I'm sorry about the empty picture, when I write this, I just copy

Re: [go-nuts] Re: use same for/range code on a hash map but it has different result

On Tue, 2020-11-10 at 19:08 -0800, 'Kilos' via golang-nuts wrote: > Thanks for reply, but I want to know the underlying reason about it, > I think the reason is in how the runtime functions works. The direct cause is that the hash function used for the map implementation is seeded from the system

[go-nuts] Re: use same for/range code on a hash map but it has different result

Thanks for reply, but I want to know the underlying reason about it, I think the reason is in how the runtime functions works. And I'm sorry about the empty picture, when I write this, I just copy the screenshot in this, the code is https://play.golang.org/p/fSPpo4_-k57 The empty picture is

Re: [go-nuts] Proposal: New keyword returnif (resolves error handling)

On Tuesday, November 10, 2020 at 6:12:18 PM UTC-5 axel.wa...@googlemail.com wrote: > IMO, `returnif , ` reads awkwardly. If anything, it should > really be `return if `. At which point it also becomes > clear that this isn't actually much of an improvement over `if { > return }`. >

Re: [go-nuts] detecting cyclic references

FYI, that does detect the simple case of l[0] = l, but not more complicated circular cases like l[1] = l[1:] On Tuesday, November 10, 2020 at 2:38:26 AM UTC-5 axel.wa...@googlemail.com wrote: > If the slice is empty, it doesn't reference anything. > If it is not empty, [0] can be used to

[go-nuts] Conditional move & hoist optimizations

Looking at how go compiles/optimizes a couple of common constructs, which I boiled down to a simple '\t' replacement loop. godbolt of sources: https://go.godbolt.org/z/Pnf3vh ``` func v1(s []byte, detab bool) (d []byte) { d = make([]byte, len(s)) for i := 0; i < len(s); i++ { char :=

Re: [go-nuts] Proposal: New keyword returnif (resolves error handling)

IMO, `returnif , ` reads awkwardly. If anything, it should really be `return if `. At which point it also becomes clear that this isn't actually much of an improvement over `if { return }`. On Tue, Nov 10, 2020 at 11:59 PM Tyler Compton wrote: > The "try proposal" and some others identified

Re: [go-nuts] Proposal: New keyword returnif (resolves error handling)

Some thoughts: The "try proposal" and some others identified and solved two problems: a. The verbosity of using a full if statement to check error values b. The verbosity of applying wrapping and other error handling logic to every place where an error is returned This proposal only addresses

Re: [go-nuts] Apple M1 chip based computers

Further investigation https://github.com/golang/go/issues/38485 appears so? Don't know properly - fairly new to Go On Tuesday, November 10, 2020 at 10:13:15 PM UTC vdha...@gmail.com wrote: > Thank you. Let me check the thread. > > Is it correct to say, for sure at least cross-compiling from, say

Re: [go-nuts] Apple M1 chip based computers

On Tue, Nov 10, 2020 at 2:13 PM Tharaneedharan Vilwanathan wrote: > > Thank you. Let me check the thread. > > Is it correct to say, for sure at least cross-compiling from, say x86-64 > ubuntu, would produce native M1 chip executable for Go programs? Assuming the M1 is Apple's version of the

Re: [go-nuts] Apple M1 chip based computers

Thank you. Let me check the thread. Is it correct to say, for sure at least cross-compiling from, say x86-64 ubuntu, would produce native M1 chip executable for Go programs? Regards dharani On Tue, Nov 10, 2020 at 1:48 PM silas poulson wrote: > >Does Go have native support for Apple M1 chip?

Re: [go-nuts] Apple M1 chip based computers

>Does Go have native support for Apple M1 chip? Earlier discussion about Apple’s other architecture changes: Imagine some work will need to be done - although given release news about including transforming app uncertain how

[go-nuts] Apple M1 chip based computers

Hi All, Sorry if this has been discussed and I missed it. I have a quick question. Does Go have native support for Apple M1 chip? Regards dharani -- 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] A Big Thank You to the Contributors of pkg.go.dev

Agreed! There was a lot of negativity surrounding pkg.go.dev regarding license detection and the original decision for it to be closed source (which was revised). These are all valid critiques, but they unfortunately overshadowed how great an experience pkg.go.dev is. Thanks to everyone who is

Re: [go-nuts] Slice header

On Tuesday, November 10, 2020 at 10:09:44 PM UTC+11 axel.wa...@googlemail.com wrote: > On Tue, Nov 10, 2020 at 11:09 AM shan...@gmail.com > wrote: > >> This seems to me to be the better solution (but it's still in the >> pipeline?) https://github.com/golang/go/issues/19367 >> an unsafe,

Re: [go-nuts] Slice header

On Tuesday, November 10, 2020 at 9:41:09 PM UTC+11 Jan Mercl wrote: Thank you for taking the time to answer, I'm still a little confused and have inlined where that confusion is below. On Tue, Nov 10, 2020 at 11:09 AM shan...@gmail.com > wrote: > > > My confusion is this, the comment says

[go-nuts] Re: use same for/range code on a hash map but it has different result

I'm not sure what strange way you decided to show your code, but in my Firefox browser all I see is two empty boxes. Please use fixed width *plain text* for all code in this group. Thanks. On Tuesday, November 10, 2020 at 9:12:54 AM UTC-5 Kilos wrote: > when I run the same code like this >

Re: [go-nuts] Re: My app hangs up at some point in net/http/h2_bundle.go. What is the better way to debug?

You can easily have the same problem on localhost if the producer is faster than the consumer. You can use netstat in the localhost as well. > On Nov 10, 2020, at 9:36 AM, Denis Telyukh wrote: > >  > Thanks for your advice. But I have this problem on localhost also, I doubt > that problem

Re: [go-nuts] Re: My app hangs up at some point in net/http/h2_bundle.go. What is the better way to debug?

Thanks for your advice. But I have this problem on localhost also, I doubt that problem in network capacity :-( вт, 10 нояб. 2020 г. в 19:09, Robert Engels : > You’ve most likely exhausted the network capacity. You need to use tools > like netperf and wireshark. Start with netstat and review the

Re: [go-nuts] How to use syscall.Syscall to call a C function accept/return a structure on Windows

On Sat, Oct 31, 2020 at 5:46 PM aihui zhu wrote: > > for example: > > void D2D1MakeRotateMatrix( > FLOAT angle, > D2D1_POINT_2F center, > D2D1_MATRIX_3X2_F *matrix > ); > and a COM based function: D2D1_SIZE_F ID2D1Bitmap_GetSize(); Based on reading

Re: [go-nuts] Generics and methods on predeclared types

On Tue, Nov 10, 2020 at 5:37 AM Markus Heukelom wrote: > > Currently the predeclared types (int, bool, float32, string, etc) do not have > any methods on them. It appears to me that if they would, the generic > implementation for math.Min/Max etc could do without 'types' in interfaces > (as is

[go-nuts] A Big Thank You to the Contributors of pkg.go.dev

Hi all, I was looking up some documentation for a go package and I was redirected to pkg.go.dev. Unlike godoc, it doesn't have an index which is my go-to for exploring the API surface of a package. I wondered if others had the same problem. Came across https://github.com/golang/go/issues/41587

[go-nuts] Re: use same for/range code on a hash map but it has different result

spec: https://golang.org/ref/spec#RangeClause point 3: ... If a map entry is created during iteration, that entry may be produced during the iteration or may be skipped. The choice may vary for each entry created and from one iteration to the next. ... On Tuesday, November 10, 2020 at 3:12:54

[go-nuts] Re: go get not downloading a module under a repository from BitBucket

Not trying to doubt you, but are you sure it's a silent failure? Where are you invoking `go get`? Is it running on module aware mode, being called within a go module? Try to run go get with "-v" to see if you get more information about what is happening. On Monday, 9 November 2020 at 03:03:09

[go-nuts] Generics and methods on predeclared types

Currently the predeclared types (int, bool, float32, string, etc) do not have any methods on them. It appears to me that if they would, the generic implementation for math.Min/Max etc could do without 'types' in interfaces (as is currently proposed). For example: type Sortable[T any]

Re: [go-nuts] Re: My app hangs up at some point in net/http/h2_bundle.go. What is the better way to debug?

You’ve most likely exhausted the network capacity. You need to use tools like netperf and wireshark. Start with netstat and review the outgoing queue sizes. > On Nov 10, 2020, at 4:46 AM, Denis Telyukh wrote: > > More complex problem description with images: >

Re: [go-nuts] go list "go:generate" files

You are right of course. But given that `go list` is aware of other directives such as build constraints I was wondering. Anyways for go code generation, it would be very helpful to be able to have a list of flies on which invoke go generate in the right order from `go list`. Giacomo On

Re: [go-nuts] Slice header

On Tue, Nov 10, 2020 at 11:09 AM shan...@gmail.com wrote: > This seems to me to be the better solution (but it's still in the > pipeline?) https://github.com/golang/go/issues/19367 > an unsafe, rather than reflect, access to the slice structure, which > allows a user to do.. interesting things

Re: [go-nuts] Re: My app hangs up at some point in net/http/h2_bundle.go. What is the better way to debug?

More complex problem description with images: https://caddy.community/t/sometimes-http-2-request-hangs-up-need-help-with-debugging/10439/2 вторник, 10 ноября 2020 г. в 10:25:58 UTC+7, Denis Telyukh: > Thanks! Maybe it will help. > > вт, 10 нояб. 2020 г. в 01:21, seank...@gmail.com : > >>

Re: [go-nuts] Slice header

On Tue, Nov 10, 2020 at 11:09 AM shan...@gmail.com wrote: > My confusion is this, the comment says (very clearly) > It's not safe, nor portable, and may change (although I have had it pointed > out to me that the comparability guarantee may contradict this) It does not. When there exists

[go-nuts] Slice header

A bit of attention has been directed at slices recently, with a few high profile blogs shining a healthy light on them (they can be traps for young players!) I'm a bit confused about SliceHeader as found in the reflect package

Re: [go-nuts] gccgo problem compiling go from source

On Tue, Nov 10, 2020 at 10:06 AM Hugo Cornelis wrote: > > Hi Mirza, > > On Thu, Nov 5, 2020 at 3:18 PM 'Mirza Krak' via golang-nuts > wrote: >> >> On Tuesday, October 20, 2020 at 9:52:17 AM UTC+2 hugo.c...@essensium.com >> wrote: >>> >>> 1. Build the gccgo cross-toolchain with Buildroot:

Re: [go-nuts] go list "go:generate" files

//go:generate is not limited to dependency on Go source files, so this is not possible in the general case. On Tue, 2020-11-10 at 01:05 -0800, gta wrote: > Thanks for the reply, > yes I know I can grep for those files, but I was hoping that go list > could give me the files in the reverse

Re: [go-nuts] gccgo problem compiling go from source

Hi Gerrit, On Mon, Nov 9, 2020 at 8:42 PM Gerrit Binnenmars wrote: > Hugo thanks for sharing your repo, I cloned the repo. Set the environment > variables GOOS and GOARCH and called mkall.sh in the unix directory. > The result is a generate:linux docker image and an _obj/_cgo_.o file in > the

Re: [go-nuts] gccgo problem compiling go from source

Hi Mirza, On Thu, Nov 5, 2020 at 3:18 PM 'Mirza Krak' via golang-nuts < golang-nuts@googlegroups.com> wrote: > On Tuesday, October 20, 2020 at 9:52:17 AM UTC+2 hugo.c...@essensium.com > wrote: > >> 1. Build the gccgo cross-toolchain with Buildroot: Buildroot currently >> builds a toolchain by

Re: [go-nuts] go list "go:generate" files

Thanks for the reply, yes I know I can grep for those files, but I was hoping that *go list *could give me the files in the reverse dependency order like *go list -deps*. I was hoping to shave some time from our generation step. I guess bash is my friend in this. Giacomo On Monday, 9