[go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write

2020-03-04 Thread Tamás Gulácsi
If the (sub)step alone is comprehensible just in itself, hiding the previous (sub)steps and its context, then it is comprehensible when refactored to a separate function. An then it is separately testable, documentable, and no collapsing esitor help is neede when viewing them main function, lis

Re: [go-nuts] How to obtain complete call chain of runtime functions in pprof, like 'mcall'

2020-03-04 Thread Xiangdong JI
Thanks Ian. I'm using schedtrace and scheddetail to help understand the scheduling flow, the minimum monitoring window seems to be 1ms only, possible to get more detailed info? Furthermore, sched* outputs extensive logs but what I expect, at present, might be something like when a goroutine is

Re: [go-nuts] Pass C struct from Go to C method

2020-03-04 Thread Nitish Saboo
Hi Ian, Thank you for the response.Got it. Basically, fmt.Println(InitStruct) is printing the values of fields, cb and data, for the struct Foo pointed by InitStruct. fmt.Printf("%p\n", InitStruct) is printing the memory address. Btw..can you please clarify the following : 1)Is this the correct w

[go-nuts] Re: Learning the runtime

2020-03-04 Thread buchanae
Turns out, other parts of the runtime have decent docs – mgc.go is very well commented, for example. I may have started my research in the darkest corners (itab, ptab, ftab, oh my). -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe

Re: [go-nuts] How to obtain complete call chain of runtime functions in pprof, like 'mcall'

2020-03-04 Thread Ian Lance Taylor
On Wed, Mar 4, 2020 at 6:44 PM Xiangdong JI wrote: > > Given the attached screenshot of pprof output, I wonder how to figure out the > callers of 'runtime.mcall' and their cost? Thanks. You can't, but it doesn't matter. The mcall function is used when a thread changes from executing one gorouti

[go-nuts] How to obtain complete call chain of runtime functions in pprof, like 'mcall'

2020-03-04 Thread Xiangdong JI
Hi, Given the attached screenshot of pprof output, I wonder how to figure out the callers of 'runtime.mcall' and their cost? Thanks. (The image is generated by profiling BenchmarkGoroutineBlocking). [image: Capture.JPG] -- You received this message because you are subscribed to the Google Gr

[go-nuts] Re: Learning the runtime

2020-03-04 Thread buchanae
> What part in particular are you interested in? I ended up in the runtime code because I'm interested in plugins, the linker, loader, and how the runtime manages types. In particular, I'm interested in https://github.com/golang/go/issues/28783. My comment here explains why: https://github.com

Re: [go-nuts] Learning the runtime

2020-03-04 Thread 'Keith Randall' via golang-nuts
There are a bunch of talks from Gophercon and elsewhere that cover pieces of the runtime: Channels: https://www.youtube.com/watch?v=KBZlN0izeiY Scheduler: https://www.youtube.com/watch?v=YHRO5WQGh0k Maps: https://www.youtube.com/watch?v=Tl7mi9QmLns [shameless self plug] Goroutines, defers, stacks

Re: [go-nuts] Re: escape analysis question

2020-03-04 Thread Ethan Burns
Thanks for looking into it and simplifying the example! Just to explain, I added the call to nothing(), because I was worried that otherwise the result would be recognized as unused and the entire code would be optimized away. Good to know it's not relevant to reproduce. Thanks again. On Wed, Mar

Re: [go-nuts] Go 1.14: how to -linkshared to a library produced by -buildmode=shared?

2020-03-04 Thread Mikhail Gusarov
Hi Bryan, On 4 Mar 2020, at 2:27, 'Bryan C. Mills' via golang-nuts wrote: Did this work in 1.13? Actually, no. In 1.13 it triggers the panic as described in this bug: https://golang.org/issue/35759 is probably related; see especially the TODO here

[go-nuts] Re: escape analysis question

2020-03-04 Thread 'Kevin Chowski' via golang-nuts
Slightly more minimal, in my testing it seems that the call to 'nothing' is not needed. I do not quite know why, but these two lines seem to show how the compiler is reasoning about this escape: escape.go:4:11: flow: {heap} = x: escape.go:4:11: from *y = x (assign) at escape.go:6:5 I do

[go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write

2020-03-04 Thread Warren Stephens
Folks, First off thanks for the feedback! -- positive and negative. Second, hopefully people can trust that I fully understand the standard approach to code refactoring and writing tests. I have done a bunch of it, and am sure will continue to do a bunch of it. I understand the merits of it

[go-nuts] escape analysis question

2020-03-04 Thread burns . ethan
Hi All, I am trying to debug why a byte slice is escaping in my program. I have a small reproducible example here: % cat escape.go package main func main() { x := make([]byte, 5) y := new([]byte) *y = x nothing((*y)[3]) } func nothing(b byte) {} % go tool compile -m -m -l escape.go escape.go:4

Re: [go-nuts] Learning the runtime

2020-03-04 Thread Ian Lance Taylor
On Tue, Mar 3, 2020 at 9:15 PM wrote: > > Is there any way to learn the internals of the runtime package, besides just > reading all the code? There are a lot of types in the package with cryptic > names and no documentation, so if all I have is the code, it's going to be a > steep learning cur

[go-nuts] Re: SIGILL running 1.14 on macOS

2020-03-04 Thread Jon Conradt
You can follow the progress toward 1.14.1 via https://github.com/golang/go/milestone/137 Looking at 1.13.0 and 1.12.0 it looks like the time between a .0 release and a .0 release is about three weeks. So I'm hoping for a St. Patrick's Day releases of 1.14.1 Jon -- You received this message b

Re: [go-nuts] How to handle EINTR from syscall.Dup2

2020-03-04 Thread Philip Boampong
On Wed, Mar 4, 2020 at 4:09 PM Ian Lance Taylor wrote: > > The links that I looked at were speculating about behavior, not > demonstrating real behavior in kernels. I don't know how to judge > whether those speculations about hypothetical behavior are correct or > not. Many things are hypothetic

Re: [go-nuts] Pass C struct from Go to C method

2020-03-04 Thread Ian Lance Taylor
On Wed, Mar 4, 2020 at 3:57 AM Nitish Saboo wrote: > > I have CGO project. > > Following is my C header file and Go code > > syslog-node.h > === > > #ifndef _TEST_H_ > #define _TEST_H_ > > #include > > typedef void (*key_value_cb)(const char* key, const char* value, size_t > value_le

[go-nuts] Re: go vet on playground emits message on printf %x with floating point

2020-03-04 Thread Jake Montgomery
This is a known problem: https://github.com/golang/go/issues/34993 It was fixed in Go 1.14: https://go-review.googlesource.com/c/tools/+/202041/ I'm curious what you use hex float for? On Tuesday, March 3, 2020 at 7:10:00 PM UTC-5, bup...@gmail.com wrote: > Playground: https://play.golang.org/p

Re: [go-nuts] How to handle EINTR from syscall.Dup2

2020-03-04 Thread Ian Lance Taylor
On Wed, Mar 4, 2020 at 6:20 AM Philip Boampong wrote: > > On Sun, Mar 1, 2020 at 3:55 PM Ian Lance Taylor wrote: > > > > If dup2 can 1) close newfd; 2) receive a signal before duping oldfd to > > newfd; 3) return EINTR leaving newfd closed, then dup2 requires > > considerable care in any multi-th

Re: [go-nuts] How to handle EINTR from syscall.Dup2

2020-03-04 Thread Philip Boampong
Thanks for the feedback. > "If the close operation fails to close fildes2, dup2() shall return -1 > without changing the open file description to which fildes2 refers." > "If close() is interrupted by a signal that is to be caught, it shall return > -1 with errno set to [EINTR] and the state of

Re: [go-nuts] How to handle EINTR from syscall.Dup2

2020-03-04 Thread Philip Boampong
On Sun, Mar 1, 2020 at 3:55 PM Ian Lance Taylor wrote: > > If dup2 can 1) close newfd; 2) receive a signal before duping oldfd to > newfd; 3) return EINTR leaving newfd closed, then dup2 requires > considerable care in any multi-threaded program. It requires that if > one thread is calling dup2,

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

2020-03-04 Thread T L
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

Re: [go-nuts] How to find goroutines during debugging - aka goroutine labeling

2020-03-04 Thread Jesper Louis Andersen
On Wed, Mar 4, 2020 at 7:24 AM Florin Pățan wrote: > I think the current solution is a perfectly reasonable solution. > > As I explained in the article, you can have 0 performance impact when used > in production environments, because you can disable this feature. > My experience is that a littl

[go-nuts] Pass C struct from Go to C method

2020-03-04 Thread Nitish Saboo
Hi, I have CGO project. Following is my C header file and Go code syslog-node.h === #ifndef _TEST_H_ #define _TEST_H_ #include typedef void (*key_value_cb)(const char* key, const char* value, size_t value_len, int work); typedef struct Foo{ key_value_cb cb; int data; }Foo

Re: [go-nuts] Go without garbage collector

2020-03-04 Thread Kevin Chadwick
On 2020-03-03 22:22, Robert Engels wrote: > A key statement in the link “ The JIT-generated code is *significantly* faster > than the ahead-of-time-generated code for small matrix sizes.” > > Which is what you were arguing was not possible... you can’t have it both > ways. JIT code often require

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

2020-03-04 Thread Tristan Colgate
It is not possible to infer the intent of a chunk of code purely from the expressions. You can see what it does, not what it meant to do. One way of labeling the intent is to put that code in a function. A well chosen name can let someone determine what the function was intended to do, and fix it i

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

2020-03-04 Thread roger peppe
On Tue, 3 Mar 2020 at 22:37, Warren Stephens wrote: > rog, > > Very well said -- but everyone keeps talking about improving the > maintainability without talking about the "comprehensiblity". > > Look at the 2 things below. Which is more quickly comprehensible? We > cannot conceive of a way to