Re: [go-nuts] Port to powerpc 440fpu

On Fri, Jul 3, 2020 at 9:36 PM Ian Lance Taylor wrote: > That looks like the process is writing to a pipe that nothing is reading > from. > Yes, that is correct. The question is: why doesn't the reader read from the pipe? And why does it suddenly start reading when the Docker daemon process is

[go-nuts] Re: decode unknown CBOR type with set of known types

By "unknown type", do you mean you want to unmarshal this CBOR map into a struct? You need some way of identifying what the data is semantically, otherwise it might unmarshal successfully into multiple different structs. I believe the CBOR native way of doing this is with "tags": https://tools

Re: [go-nuts] composite literal uses unkeyed fields

I'm using unkeyed fields for the opposite reason: I don't want code to compile when I add new fields to the struct, unless this is reflected at the other end. For example, I found it very useful sometimes, to pass a long list of arguments to the function through a struct. The same would happen

[go-nuts] [generics] Data structures and the garbage collector

Hi, Many data structures are implemented using pointers. How does this perform wrt garbage collecting? For example take any data structure that uses some tree of nodes, or even simpler just a singly linked list: there is one pointer from the left node to the next. Wouldn't this incur huge GC (

[go-nuts] What is the the gccgo equivalent of -X importpath.name=value

Hi All As part of porting to powerpc440 effort, we are using gccgo to port Docker. I am confused about the -X flag. What is the gccgo equivalent of using -X importpath.name=value to set string variables in some go files. The following command GO111MODULE=off GOARCH=ppc GOCACHE="/workspace/out

[go-nuts] Re: decode unknown CBOR type with set of known types

Hi Jonathan, Thanks for the suggestion. I'm going to take this approach of using a wrapping struct like in your example. Although it might be possible to solve this problem with CBOR tags this seems more difficult and possibly not supported by the existing go CBOR libraries. Cheers, David O

[go-nuts] Re: casting arbitrary int to unsafe.Pointer: go test -race (checkptr) complains

As far as I see, you pass c.id to go_readcallback, which gets the stream from streamsMap. Why unsafe.Pointer and uintptr? Why not just a simple int or uint32 ? For map key, they're indifferent, and the unsafe.Pointer is totally uneeded here. 2020. július 9., csütörtök 18:58:52 UTC+2 időpontba

Re: [go-nuts] [generics] Data structures and the garbage collector

On Thu, Jul 9, 2020 at 9:40 AM Markus Heukelom wrote: > > Many data structures are implemented using pointers. How does this perform > wrt garbage collecting? For example take any data structure that uses some > tree of nodes, or even simpler just a singly linked list: there is one > pointer fr

Re: [go-nuts] What is the the gccgo equivalent of -X importpath.name=value

On Thu, Jul 9, 2020 at 9:40 AM Atilla Filiz wrote: > > As part of porting to powerpc440 effort, we are using gccgo to port Docker. > > I am confused about the -X flag. What is the gccgo equivalent of using -X > importpath.name=value to set string variables in some go files. > > The following comm

Re: [go-nuts] [Arm32] float/NaN/int issue (fixed for me, posting for info/discussion/bug report?)

yes, agreed, just pushing to the extrema. On Thursday, 9 July 2020 01:32:13 UTC+1, keith@gmail.com wrote: > > > > On Wednesday, July 8, 2020 at 4:50:30 PM UTC-7, simon place wrote: >> >> wait a minute, so this... https://play.golang.org/p/x5SQVgSJsIs >> >> could return anything! >> >> > I thi

[go-nuts] [security] Go 1.14.5 and Go 1.13.13 pre-announcement

Hello gophers, We plan to issue Go 1.14.5 and Go 1.13.13 on Tuesday, July 14. These are minor releases that include multiple security fixes. Following our policy at https://golang.org/security, this is the pre-announcement of those releases. Cheers, Katie and Filippo on behalf of the Go t

[go-nuts] exec.Cmd.Process.Kill doesn't unblock exec.Cmd.Wait

I am using Go 1.14 AMD64 on Linux 5.3.0. When I create a subprocess with exec.Cmd.Start, I can't seem to fully kill it with exec.Cmd.Process.Kill, or at least not to the satisfaction of exec.Cmd.Wait. I am doing something along the lines of: cmd := exec.Command(binPath) if err := cmd.Start(); e

Re: [go-nuts] exec.Cmd.Process.Kill doesn't unblock exec.Cmd.Wait

On Thu, Jul 9, 2020 at 4:14 PM Ian Gudger wrote: > > I am using Go 1.14 AMD64 on Linux 5.3.0. > > When I create a subprocess with exec.Cmd.Start, I can't seem to fully kill it > with exec.Cmd.Process.Kill, or at least not to the satisfaction of > exec.Cmd.Wait. > > I am doing something along the

[go-nuts] Re: casting arbitrary int to unsafe.Pointer: go test -race (checkptr) complains

Because the C function I'm calling takes a "void *" param. Can you pass a regular Go int as a "void *" argument somehow without going through unsafe.Pointer? Note I don't directly call go_readcallback; I call op_open_callbacks (not under my control) and pass it the go_readcallback as a callback

[go-nuts] Re: casting arbitrary int to unsafe.Pointer: go test -race (checkptr) complains

Just write a wrapper on the C side (in the import "C" code) that takes a uintptr and casts it to void*. func wrapper(a uintptr, b, c, d, e ...) { op_open_callbacks((void*)a, b, c, d, e) } Then you can call C.wrapper and pass it s.id directly. On Thursday, July 9, 2020 at 4:17:08 PM UTC-7, Hra

Re: [go-nuts] exec.Cmd.Process.Kill doesn't unblock exec.Cmd.Wait

Thanks for pointing me to the bug. This is happening to me even with nil or *os.File Stdout and Stderr (I tried both). Is there anything that can be done to guarantee that exec.Cmd.Wait won't block indefinitely? I don't think my subprocess is starting any of its own subprocesses, but I am not comp

[go-nuts] [generics] Casting to an interface with type constraints produces an internal error in the go2go playground

Expected behavior: I think it should fail on the type checking step saying we cannot have a variable of that type Steps to reproduce: https://go2goplay.golang.org/p/RVTj-tORXip -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from

[go-nuts] Re: run golang cpu profile for 5mins but only got 1.64mins (32.69%) samples

Thank you Volker. From the golang document, when getting cpu profile, it will stop the golang runtime 100 times per second, so I think for 5 mins, there should be 5*60*1000 samples. Am I wrong? 在 2020年7月1日星期三 UTC+8下午4:39:18，Volker Dobler写道： > > On Tuesday, 30 June 2020 18:16:54 UTC+2, lqiy...@gm

[go-nuts] Strings with blank convert to bytes

Hello everyone: I use golang with Win10. The version of golang I used is go1.12.9. This is a simple code I'm trying to figure out. However, I have no idea how to edit to make the output "b1" the same as "b" if "b1" is read from user input. Could anyone help

[go-nuts] Re: Strings with blank convert to bytes

Hello! Just quote the document: > Scanf scans text read from standard input, storing successive space-separated values into successive arguments as determined by the format Instead, you can use fmt.Scanln. On Friday, July 10, 2020 at 10:03:26 AM UTC+8 max1...@gmail.com wrote: > Hello everyone:

[go-nuts] Re: Strings with blank convert to bytes

Hello! The problem isn't solve when I use "fmt.Scanln" instead of "fmt.Scanf". That is, the result is the same whatever I use "fmt.Scanln" or "fmt.Scanf". Thanks for your replying. Max tokers於 2020年7月10日星期五 UTC+8上午10時12分04秒寫道： > > Hello! > > Just quote the document: > > > Scanf scans text read fr

Re: [go-nuts] Re: Strings with blank convert to bytes

On Thu, Jul 9, 2020 at 7:23 PM 洪嘉鴻 wrote: > Hello! > The problem isn't solve when I use "fmt.Scanln" instead of "fmt.Scanf". > That is, the result is the same whatever I use "fmt.Scanln" or "fmt.Scanf". > >From the documentation: the %s verb (and %v reading into a string) stops consuming input

Re: [go-nuts] Re: Strings with blank convert to bytes

Hello! I've just found this according the information which you provided. Although there is a little different that it also reads "\n" with ReadString(). However, it solves my problem. Thanks for your

Re: [go-nuts] exec.Cmd.Process.Kill doesn't unblock exec.Cmd.Wait

On Thu, Jul 9, 2020 at 5:52 PM Ian Gudger wrote: > > Thanks for pointing me to the bug. > > This is happening to me even with nil or *os.File Stdout and Stderr (I tried > both). Is there anything that can be done to guarantee that exec.Cmd.Wait > won't block indefinitely? I don't think my subpro

Re: [go-nuts] [generics] Casting to an interface with type constraints produces an internal error in the go2go playground

On Thu, Jul 9, 2020 at 6:08 PM Alexandr Gulak wrote: > > Expected behavior: I think it should fail on the type checking step saying we > cannot have a variable of that type > > Steps to reproduce: https://go2goplay.golang.org/p/RVTj-tORXip I agree that it looks like the type checker should repor

Re: [go-nuts] What is the the gccgo equivalent of -X importpath.name=value

Hi Ian I am thinking of ways to work around this then. I come from C world. There we use an undefined symbol, and define it using the -D flag to the compiler. Since Go has no preprocessor, this is probably not an option. Another option could be some binutil trick to remove a symbol an re-add it