[go-nuts] Re: go build doesn't propagate options that disable optimizations

My understanding is that you do not need -a anymore, just the rest of the flags. -- 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...@googlegro

[go-nuts] Re: Would this race condition be considered a bug?

Any race is a bug. When there is a race, the compiler is free to do whatever it wants. What do you want to do? Do you want to println before or after cancelContext? In your example, println could even be executed during cancelContext! Your example is not enough, such program : https://play.gol

Re: [go-nuts] Goroutines, Nonblocking I/O, And Memory Usage

Hi! On Thu, Mar 15, 2018 at 09:09:18AM -0700, Rio wrote: > Yeah, there's no way to avoid the kernel buffer waste. You can tune kernel buffer size to minimize it. > > I did such a custom poller for a network proxy. It was a pain > > to get right (I only did the Eww!poll version). > > I tried an

Re: [go-nuts] Closing os.Stdin while trying to read from it?

Hi! On Thu, Mar 15, 2018 at 12:49:15PM +, roger peppe wrote: > If it helps, you can set deadlines on *os.File now, as of Go 1.10: > >https://play.golang.org/p/h3Pg9Ql0CMB > > I don't see a way to cancel without deciding the deadline in advance though. Why? What makes os.Stdin so special

[go-nuts] The result of yaml.Unmarshal() is different between osX and linux

Recently I started to use golang in project and I got one problem. The problem is the result of yaml.Unmarshal when I put invalid yaml is different between osX and linux. My environments are here macOS Sierra 10.12.6 go version go1.10 darwin/amd64 Linux version 3.10.0-693.11.6.el7.x86_64 go

[go-nuts] getting an error for simple go program with for loop in MAC OSX 10.13.13

Hello All, I am getting a below error in MAC OSX 10.13.13. I am using 1.10 version. go/1.10/libexec/src/crypto/x509/root_cgo_darwin.go:104:2: error: 'for' loop initial declarations are only allowed in C99 or C11 mode

Re: [go-nuts] The result of yaml.Unmarshal() is different between osX and linux

package main import ( "fmt" "io/ioutil" "os" yaml "gopkg.in/yaml.v2" ) type [...] This is hard to read. Please post your code with proper line breaks. Lutz -- 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] Closing os.Stdin while trying to read from it?

On Fri, Mar 16, 2018 at 5:29 AM, Alex Efros wrote: > > On Thu, Mar 15, 2018 at 12:49:15PM +, roger peppe wrote: >> If it helps, you can set deadlines on *os.File now, as of Go 1.10: >> >>https://play.golang.org/p/h3Pg9Ql0CMB >> >> I don't see a way to cancel without deciding the deadline i

Re: [go-nuts] getting an error for simple go program with for loop in MAC OSX 10.13.13

Please file a bug at https://golang.org/issue, including all the information on the template. Thanks. Ian On Fri, Mar 16, 2018 at 5:15 AM, avinash dhananjaya < avinash.dhanan...@gmail.com> wrote: > > Hello All, > > I am getting a below error in MAC OSX 10.13.13. I am using 1.10 version. > > go/

Re: [go-nuts] The result of yaml.Unmarshal() is different between osX and linux

You’re getting an error on the file read. Print the error to see what it is, instead of a hardcoded string. On 16 Mar 2018, at 08:24, dev.ys084...@gmail.com wrote: Recently I started to use golang in project and I got one problem. The problem is the result of yam

[go-nuts] Re: How to reuse go fix tool code

Anuj Agrawal, Exporting an API carries a commitment to maintain and support that API. go fix was a special-purpose command, that was useful before the Go1 compatibility guarantee. I can see no reason to export a go fix API. Peter On Thursday, March 15, 2018 at 6:20:47 AM UTC-4, Anuj Agrawal wr

[go-nuts] Re: Would this race condition be considered a bug?

sync.Mutex is an easy way to guard shared resources. I’ve heard hints to use channels instead of a mutex though. Matt On Thursday, March 15, 2018 at 9:11:49 PM UTC-5, Anmol Sethi wrote: > > https://play.golang.org/p/82Um1jSntBo > > Please run with the race detector to see the race. > > This race

[go-nuts] Re: The result of yaml.Unmarshal() is different between osX and linux

Sorry, I thought I can send code with proper line breaks. I will write code again with showing error. Also, I tried to make code simpler. invalid.yaml namespace: name: bbb description: c format:: type: sample file: foo.sh main.go package main import ( "fmt" "io/ioutil" "os" ya

Re: [go-nuts] Would this race condition be considered a bug?

On 16 March 2018 at 02:11, 'Anmol Sethi' via golang-nuts wrote: > https://play.golang.org/p/82Um1jSntBo > > Please run with the race detector to see the race. > > This race condition arises because private variables are read via reflection > by the fmt package. Is there any elegant way to avoid su

[go-nuts] Long running task in select case

All the examples I've seen use some kind of ticker to run various cases of a select statement. But how does one run a long running task that is still cancelable? In the example below the quit part is never reached. https://play.golang.org/p/PLGwrUvKaqn (it does not run properly on pla

Re: [go-nuts] The result of yaml.Unmarshal() is different between osX and linux

Could you please create a self-contained example where the YAML is inside the code itself (use a back-quoted string containing the YAML)? Also, could you please confirm the git commit hashes of the YAML you're using on each platform? If you're using a different version on each platform, please co

Re: [go-nuts] Long running task in select case

On Fri, Mar 16, 2018 at 8:45 AM, Sathish VJ wrote: > All the examples I've seen use some kind of ticker to run various cases of a > select statement. But how does one run a long running task that is still > cancelable? > > > In the example below the quit part is never reached. > > https://play.go

Re: [go-nuts] Long running task in select case

On 16 March 2018 at 14:45, Sathish VJ wrote: > All the examples I've seen use some kind of ticker to run various cases of a > select statement. But how does one run a long running task that is still > cancelable? > > > In the example below the quit part is never reached. > > https://play.golang.o

[go-nuts] Re: Long running task in select case

> > While this is running, your select won't be receiving on the quit > channel, even if it is non-nil. > If you want to be able to cancel it, you'll need to make the code in > the loop responsive to the quit channel > (for example, by using a select like you're using in f already). The def

Re: [go-nuts] The result of yaml.Unmarshal() is different between osX and linux

> > Thank you for your message. I tried to exec with back-quoted string and check git hash number again. The code which I ran is package main import ( "fmt" yaml "gopkg.in/yaml.v2" ) type Sample struct { Namespace string `yaml:"namespace"` Namestring `yaml:"name"` Description stri

[go-nuts] Re: go build doesn't propagate options that disable optimizations

For completeness, this is documented in the 1.10 release notes. See the second paragraph of this section: https://golang.org/doc/go1.10#build. On Thursday, March 15, 2018 at 3:16:37 PM UTC-4, matthe...@gmail.com wrote: > > This looks like it changed between 1.9.4 and 1.10. > > Here’s the document

[go-nuts] int int32 int64

Hello Golangnuts, I'm experiencing unexpected behavior. Trying to reverse integer. This code works on 64-bit machine, but working wrong on 32-bit: https://play.golang.org/p/p4Ptu8cx-b7 How can I generate an error in this case? Thanks -- You received this message because you are subscribed t

Re: [go-nuts] int int32 int64

On Fri, Mar 16, 2018 at 12:11 PM, Alex Dvoretskiy wrote: > Hello Golangnuts, > > I'm experiencing unexpected behavior. Trying to reverse integer. > > This code works on 64-bit machine, but working wrong on 32-bit: > > https://play.golang.org/p/p4Ptu8cx-b7 on 32-bit machine, int is 32 bits, and th

Re: [go-nuts] The result of yaml.Unmarshal() is different between osX and linux

I was more interested in the specific version of yaml you were using. What does this command print for you on each platform? git --git-dir $(go list -f '{{.Dir}}' gopkg.in/yaml.v2)/.git log -1 (I'm assuming you use the bash shell). thanks. rog. On 16 March 2018 at 15:24, Yuichi Sawada wr

Re: [go-nuts] About 64bits alignment

On Thursday, March 15, 2018 at 12:54:22 PM UTC-4, Ian Lance Taylor wrote: > > On Thu, Mar 15, 2018 at 8:11 AM, T L > > wrote: > > > > On Thursday, March 15, 2018 at 10:57:50 AM UTC-4, Jan Mercl wrote: > >> > >> > >> On Thu, Mar 15, 2018 at 3:29 PM T L wrote: > >> > >> > I mean "always ma

[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 becau

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 to the Google Groups

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: https://play.golang.org/p/nY-BB3t0IAw > > >

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 not struct{} >> >> If desired, it can be

Re: [go-nuts] The result of yaml.Unmarshal() is different between osX and linux

Thank you for your pointing out. This problem is occur by the difference of yaml veresion. When I use same version of YAML, I got same results. In Mac I use commit d670f9405373e636a5a2765eea47fac0c9bc91a4 (HEAD -> v2, origin/v2, origin/master, origin/HEAD) Merge: 1244d3c 1f1f618 Author: Roger P

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: >>> >>> >>> > I feel the second append call sho

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: On Fri, Mar 16, 2