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

[Florin Pățan]

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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jérôme Champion]

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.golang.org/p/KJsYwu-ivjb would fix your problem, but I don't 
think that's what you asked for :)

Le vendredi 16 mars 2018 03:11:49 UTC+1, Anmol Sethi a écrit :
>
> 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 such a 
> race?
>
> -- 
> Best,
> Anmol
>
>

-- 
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 options, visit https://groups.google.com/d/optout.

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

[Alex Efros]

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 and it was indeed a lot of work.

There are some existing implementations which may helps a bit, for ex.
https://godoc.org/github.com/mailru/easygo/netpoll

-- 
WBR, Alex.

-- 
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 options, visit https://groups.google.com/d/optout.

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

[Alex Efros]

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?

If we add this at beginning of main() it'll work as expected:
os.Stdin, _ = os.Open("/dev/stdin")

-- 
WBR, Alex.

-- 
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 options, visit https://groups.google.com/d/optout.

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

[dev . ys084743]

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 version go1.10 linux/amd64


This is my code I ran.

invalid.yaml: 

-
  namespace: 
name: bbb
 description:  hy
maintainer: du...@example.com
version: 1.1.1
format::
  :type: sample
  file: ./foo.sh

-

main.go:

-

package main import ( "fmt" "io/ioutil" "os" yaml "gopkg.in/yaml.v2" ) type 
Sample struct { Namespace string `yaml:"namespace"` Name string 
`yaml:"name"` Description string `yaml:"description"` Maintainer string 
`yaml:"maintainer"` Version string `yaml:"version"` Format struct { Type 
string `yaml:"type"` File string `yaml:"file"` } `yaml:"format"` } const ( 
validYaml = "./valid.yaml" invalidYaml = "./invalid.yaml" ) func main() { 
data2, err := ioutil.ReadFile(invalidYaml) if err != nil { fmt.Println("It 
will not come here 2") os.Exit(1) } sample2 := &Sample{} err = 
yaml.Unmarshal(data2, sample2) if err != nil { fmt.Println("Should come 
here") os.Exit(0) } fmt.Println("It will not come here!!") os.Exit(1) }

-

Expect to see osX "Should come here"

linux
"Should come here"

See instead
osX
"Should come here"
linux
"It will not come here!!"

First time I thought this is a problem of library but the library looks like 
does not have the difference between linux and osX.
So I ask this problem here.


I hope to fix this problem.

Thank you

Yuichi

-- 
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 options, visit https://groups.google.com/d/optout.

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

[avinash dhananjaya]

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




-- 
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 options, visit https://groups.google.com/d/optout.

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

[Lutz Horn]

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 receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ian Lance Taylor]

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 in advance though.
>
> Why? What makes os.Stdin so special?
>
> If we add this at beginning of main() it'll work as expected:
> os.Stdin, _ = os.Open("/dev/stdin")

What is special about os.Stdin is the way it is initialized, which is
to say it is normally in blocking mode, and therefore reads block even
if you close the descriptor in a different goroutine.  This would be
affected by changes to https://golang.org/issue/22939.

Ian

-- 
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 options, visit https://groups.google.com/d/optout.

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

[Ian Lance Taylor]

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/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
>
>
>
> 
>
> --
> 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 options, visit https://groups.google.com/d/optout.
>

-- 
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 options, visit https://groups.google.com/d/optout.

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

[Jakob Borg]

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 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 version go1.10 linux/amd64


This is my code I ran.

invalid.yaml:

-
  namespace: 
name: bbb
 description:  hy
maintainer: du...@example.com
version: 1.1.1
format::
  :type: sample
  file: ./foo.sh


-

main.go:

-

package main import ( "fmt" "io/ioutil" "os" yaml 
"gopkg.in/yaml.v2" ) type Sample struct { Namespace 
string `yaml:"namespace"` Name string `yaml:"name"` Description string 
`yaml:"description"` Maintainer string `yaml:"maintainer"` Version string 
`yaml:"version"` Format struct { Type string `yaml:"type"` File string 
`yaml:"file"` } `yaml:"format"` } const ( validYaml = "./valid.yaml" 
invalidYaml = "./invalid.yaml" ) func main() { data2, err := 
ioutil.ReadFile(invalidYaml) if err != nil { fmt.Println("It will not come here 
2") os.Exit(1) } sample2 := &Sample{} err = yaml.Unmarshal(data2, sample2) if 
err != nil { fmt.Println("Should come here") os.Exit(0) } fmt.Println("It will 
not come here!!") os.Exit(1) }

-

Expect to see osX "Should come here"

linux
"Should come here"

See instead
osX
"Should come here"
linux
"It will not come here!!"

First time I thought this is a problem of library but the library looks like 
does not have the difference between linux and osX.
So I ask this problem here.


I hope to fix this problem.

Thank you


Yuichi

--
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 options, visit https://groups.google.com/d/optout.

-- 
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 options, visit https://groups.google.com/d/optout.

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

[peterGo]

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 wrote:
>
> Hi, 
>
> I am looking to create a gofix for one of my projects. I thought of 
> importing the code in 
> https://github.com/golang/go/tree/master/src/cmd/fix so that I could 
> simply write a plugin, build a binary and give it to people who import 
> my code. 
>
> However, I do not see any exported symbols in this code. That leaves 
> me with only one choice - that I copy the code and then write the 
> plugin on top of it. That does not sound like a very great idea as 
> compared to being able to import the package itself. 
>
> Is there any particular reason for not exporting any symbols in the gofix 
> code? 
>
> Thanks, 
> Anuj Agrawal 
>

-- 
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 options, visit https://groups.google.com/d/optout.

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

[matthewjuran]

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 condition arises because private variables are read via 
> reflection by the fmt package. Is there any elegant way to avoid such a 
> race?
>
> -- 
> Best,
> Anmol
>
>

-- 
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 options, visit https://groups.google.com/d/optout.

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

[y . 084743]

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"

yaml "gopkg.in/yaml.v2"
)

type Sample struct {
Namespace   string `yaml:"namespace"`
Namestring `yaml:"name"`
Description string `yaml:"description"`
Format  struct {
Type string `yaml:"type"`
File string `yaml:"file"`
} `yaml:"format"`
}

const (
invalidYaml = "./invalid.yaml"
)

func main() {
data, err := ioutil.ReadFile(invalidYaml)
if err != nil {
os.Exit(1)
}
sample := &Sample{}
err = yaml.Unmarshal(data, sample)
fmt.Printf("%v", err)
}


Expect to see
  osX


  linux


 or

  osX

yaml: line 1: did not find expected 

  linux

yaml: line 1: did not find expected 

See instead

osX yaml: line 1: did not find expected 

  linux




Sorry Thank you.

-- 
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 options, visit https://groups.google.com/d/optout.

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

[roger peppe]

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 such a race?

Why are you using %#v? It can print all kinds of internal details
including, as you've found, fields that are mutex-guarded.
Why not use (say) %v instead?

-- 
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 options, visit https://groups.google.com/d/optout.

[go-nuts] Long running task in select case

[Sathish VJ]

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 
play.golang.org).

package main


import (
 "fmt"
 "os"
 "time"
)


func f(quit chan bool) {
 for {
   select {
   case <-time.After(0 * time.Second):
 // start long running task immediately.
 for {
   time.Sleep(500 * time.Millisecond)
   fmt.Printf(". ")
 }
   case <-quit:
 fmt.Println("quit called")
 //deallocate resources in other long running task and then return from 
function.
 os.Exit(0) // or return
   }
 }
}


func main() {
 var quit chan bool
 go f(quit)


 println("quit sending ... ")
 quit <- true
 println("after quit sent")


 var i chan int
 <-i
}


-- 
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 options, visit https://groups.google.com/d/optout.

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

[roger peppe]

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 confirm
that your still see the difference in behaviour when you checkout
the same version on each.

  thanks,
rog.

On 16 March 2018 at 07:24,   wrote:
> 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 version go1.10 linux/amd64
>
>
> This is my code I ran.
>
> invalid.yaml:
>
> -
>   namespace: 
> name: bbb
>  description:  hy
> maintainer: du...@example.com
> version: 1.1.1
> format::
>   :type: sample
>   file: ./foo.sh
>
> -
>
> main.go:
>
> -
>
> package main
>
> import (
> "fmt"
> "io/ioutil"
> "os"
>
> yaml "gopkg.in/yaml.v2"
> )
>
> type Sample struct {
> Namespace   string `yaml:"namespace"`
> Namestring `yaml:"name"`
> Description string `yaml:"description"`
> Maintainer  string `yaml:"maintainer"`
> Version string `yaml:"version"`
> Format  struct {
> Type string `yaml:"type"`
> File string `yaml:"file"`
> } `yaml:"format"`
> }
>
> const (
> validYaml   = "./valid.yaml"
> invalidYaml = "./invalid.yaml"
> )
>
> func main() {
> data2, err := ioutil.ReadFile(invalidYaml)
> if err != nil {
> fmt.Println("It will not come here 2")
> os.Exit(1)
> }
> sample2 := &Sample{}
> err = yaml.Unmarshal(data2, sample2)
> if err != nil {
> fmt.Println("Should come here")
> os.Exit(0)
> }
> fmt.Println("It will not come here!!")
> os.Exit(1)
> }
>
> -
>
> Expect to see
> osX
> "Should come here"
>
> linux
> "Should come here"
>
> See instead
> osX
> "Should come here"
> linux
> "It will not come here!!"
>
> First time I thought this is a problem of library but the library looks like
> does not have the difference between linux and osX.
> So I ask this problem here.
>
>
> I hope to fix this problem.
>
> Thank you
>
> Yuichi
>
> --
> 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 options, visit https://groups.google.com/d/optout.

-- 
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 options, visit https://groups.google.com/d/optout.

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

[Burak Serdar]

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.golang.org/p/PLGwrUvKaqn  (it does not run properly on
> play.golang.org).
>
> package main
>
>
> import (
>  "fmt"
>  "os"
>  "time"
> )
>
>
> func f(quit chan bool) {
>  for {
>select {
>case <-time.After(0 * time.Second):
>  // start long running task immediately.
>  for {
>time.Sleep(500 * time.Millisecond)
>fmt.Printf(". ")
>  }
>case <-quit:
>  fmt.Println("quit called")
>  //deallocate resources in other long running task and then return from
> function.
>  os.Exit(0) // or return
>}
>  }
> }
>
>
> func main() {
>  var quit chan bool

'quit' is nil. Replace this with

quit:=make(chan bool)

>  go f(quit)
>
>
>  println("quit sending ... ")
>  quit <- true
>  println("after quit sent")
>
>
>  var i chan int
>  <-i
> }
>
>
> --
> 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 options, visit https://groups.google.com/d/optout.

-- 
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 options, visit https://groups.google.com/d/optout.

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

[roger peppe]

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.org/p/PLGwrUvKaqn  (it does not run properly on
> play.golang.org).
>
> package main
>
>
> import (
>  "fmt"
>  "os"
>  "time"
> )
>
>
> func f(quit chan bool) {
>  for {
>select {
>case <-time.After(0 * time.Second):
>  // start long running task immediately.
>  for {
>time.Sleep(500 * time.Millisecond)
>fmt.Printf(". ")
>  }

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).

>case <-quit:
>  fmt.Println("quit called")
>  //deallocate resources in other long running task and then return from
> function.
>  os.Exit(0) // or return
>}
>  }
> }
>
>
> func main() {
>  var quit chan bool
>  go f(quit)
>
>
>  println("quit sending ... ")
>  quit <- true
>  println("after quit sent")
>
>
>  var i chan int
>  <-i
> }
>
>
> --
> 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 options, visit https://groups.google.com/d/optout.

-- 
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 options, visit https://groups.google.com/d/optout.

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

[matthewjuran]

>
> 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 default select case does it: https://play.golang.org/p/jlfaXu6TZ8L

Here's another way: https://play.golang.org/p/gEDef3LolAZ

Matt

On Friday, March 16, 2018 at 9:45:00 AM UTC-5, 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.org/p/PLGwrUvKaqn  (it does not run properly on 
> play.golang.org).
>
> package main
>
>
> import (
>  "fmt"
>  "os"
>  "time"
> )
>
>
> func f(quit chan bool) {
>  for {
>select {
>case <-time.After(0 * time.Second):
>  // start long running task immediately.
>  for {
>time.Sleep(500 * time.Millisecond)
>fmt.Printf(". ")
>  }
>case <-quit:
>  fmt.Println("quit called")
>  //deallocate resources in other long running task and then return 
> from function.
>  os.Exit(0) // or return
>}
>  }
> }
>
>
> func main() {
>  var quit chan bool
>  go f(quit)
>
>
>  println("quit sending ... ")
>  quit <- true
>  println("after quit sent")
>
>
>  var i chan int
>  <-i
> }
>
>
>

-- 
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 options, visit https://groups.google.com/d/optout.

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

[Yuichi Sawada]

>
> 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 string `yaml:"description"`
Format  struct {
Type string `yaml:"type"`
File string `yaml:"file"`
} `yaml:"format"`
}

const invalidYaml = `
 namespace: 
name: bbb
description: c
format::
  type: sample
file: foo.sh
`

func main() {
fmt.Println(invalidYaml)
sample := &Sample{}
err := yaml.Unmarshal([]byte(invalidYaml), sample)
fmt.Printf("%v\n", err)
}

The result in mac is here
% sw_vers; go version; git log --oneline -1; go run main.go

(git)-[master]
ProductName:Mac OS X
ProductVersion: 10.12.6
BuildVersion:   16G1036
go version go1.10 darwin/amd64
201773b (HEAD -> master, origin/master, origin/HEAD) add line break

 namespace: 
name: bbb
description: c
format::
  type: sample
file: foo.sh

yaml: line 2: did not find expected 

The result in linux is here
cat /proc/version; go version; git log --oneline -1; go run main.go
Linux version 3.10.0-693.11.6.el7.x86_64 (buil...@kbuilder.dev.centos.org) 
(gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) ) #1 SMP Thu Jan 4 
01:06:37 UTC 2018
go version go1.10 linux/amd64
201773b add line break

 namespace: 
name: bbb
description: c
format::
  type: sample
file: foo.sh



Am I answer collect?

Thank you.
Yuichi

-- 
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 options, visit https://groups.google.com/d/optout.

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

[jake6502]

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 documentation: 
> https://github.com/golang/go/blob/release-branch.go1.10/src/cmd/go/internal/work/build.go#L113-L127
>
> I guess the package patterns thing is new. Try this:
>
> go build -a -x -gcflags=“all=-N -l”
>
> Matt
>
> On Thursday, March 15, 2018 at 1:52:28 PM UTC-5, Patrick Turley wrote:
>>
>> I build my Go project with the -N and -l options, but they only seem to 
>> apply to the top-most package -- imported packages are still optimized.  
>> From what I can tell, this is because go build isn't propagating the 
>> options that disable optimization as it tracks down and builds dependencies.
>>
>> I *claim* that:
>>
>>
>>- If I tell  go build  to disable optimizations, it makes sense that 
>>optimizations should be disabled for *everything* it ends up building.
>>
>>- Therefore, this is a bug.
>>
>>
>> I'm writing here because I'm a Go n00b, and there may be something I'm 
>> missing.
>>
>> Let me show my evidence...
>>
>> Consider the following trivial Go project:
>>
>> .
>> ├── main.go
>> └── help
>> └── help.go
>>
>>
>>
>> Here's main.go:
>>
>>
>> package main
>>
>> import "./help"
>>
>> func main() {
>> help.Help()
>> }
>>
>>
>>
>> Here's help.go:
>>
>>
>> package help
>>
>> import "fmt"
>>
>> func Help() {
>> fmt.Println("I'm helping")
>> }
>>
>>
>>
>> Here's how I built the project:
>>
>>
>> go build -gcflags="-N -l" main.go
>>
>>
>>
>> The -N option disables optimization, and the -l option disables inlining.
>>
>> This produced an executable called main in my current directory (as 
>> expected).  I tried to debug this executable with delve and saw this:
>>
>>
>> $ dlv exec main
>> Type 'help' for list of commands.
>> (dlv) b main.main
>> Breakpoint 1 set at 0x108e83f for main.main() ./main.go:5
>> (dlv) c
>> > main.main() ./main.go:5 (hits goroutine(1):1 total:1) (PC: 0x108e83f)
>>  1: package main
>>  2:
>>  3: import "./help"
>>  4:
>> =>   5: func main() {
>>  6: help.Help()
>>  7: }
>> (dlv) s
>> > main.main() ./main.go:6 (PC: 0x108e84b)
>>  1: package main
>>  2:
>>  3: import "./help"
>>  4:
>>  5: func main() {
>> =>   6: help.Help()
>>  7: }
>> (dlv) s
>> > _/Users/pturley/Workspace/Go/src/debug-problem/help.Help() 
>> ./help/help.go:5 (PC: 0x108e76f)
>> Warning: debugging optimized function
>>  1: package help
>>  2:
>>  3: import "fmt"
>>  4:
>> =>   5: func Help() {
>>  6: fmt.Println("I'm helping")
>>  7: }
>>
>>
>>
>> Notice that main() isn't optimized (as expected), but Help() is 
>> optimized, and delve prints a warning about that.  If, for example, 
>> Help() had local variables, it would be unlikely you could view their 
>> values.
>>
>> I tried building again with a few more options:
>>
>>
>> go build -a -x -gcflags="-N -l" main.go > log 2>&1
>>
>>
>>
>> The -a option ensures Go doesn't rely on any cached build artifacts.  The 
>> -x option causes Go to print all commands before executing them.
>>
>> Here's the command that built main.go (white space inserted to improve 
>> clarity):
>>
>>
>> /opt/local/lib/go/pkg/tool/darwin_amd64/compile
>> -o $WORK/b001/_pkg_.a
>> -trimpath $WORK/b001
>> -N -l
>> -p main
>> -complete
>> -buildid XMSzm8g7wNG80cfFP4Nw/XMSzm8g7wNG80cfFP4Nw
>> -goversion go1.10
>> -D _/Users/pturley/Workspace/Go/src/debug-problem
>> -importcfg $WORK/b001/importcfg
>> -pack -c=4
>> ./main.go
>>
>>
>>
>> Here's the command that built help.go:
>>
>>
>> /opt/local/lib/go/pkg/tool/darwin_amd64/compile
>> -o $WORK/b002/_pkg_.a
>> -trimpath $WORK/b002
>> -p _/Users/pturley/Workspace/Go/src/debug-problem/help
>> -complete
>> -buildid Td3vdeSGgO-nwcrs810U/Td3vdeSGgO-nwcrs810U
>> -goversion go1.10
>> -D _/Users/pturley/Workspace/Go/src/debug-problem/help
>> -importcfg $WORK/b002/importcfg
>> -pack -c=4
>> ./help.go
>>
>>
>>
>> Note that the -N and -l options are missing in the latter command.  If 
>> they had been propagated by  go build (which I *claim* makes the most 
>> sense), *all* my code would be debuggable.
>>
>>

-- 
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 options, visit https://groups.google.com/d/optout.

[go-nuts] int int32 int64

[Alex Dvoretskiy]

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 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 options, visit https://groups.google.com/d/optout.

Re: [go-nuts] int int32 int64

[Burak Serdar]

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 that number overflows. Declare
your variables as int64, and it should work.

>
> How can I generate an error in this case?
>
> Thanks
>
> --
> 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 options, visit https://groups.google.com/d/optout.

-- 
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 options, visit https://groups.google.com/d/optout.

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

[roger peppe]

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  wrote:
>> 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 string `yaml:"description"`
> Format  struct {
> Type string `yaml:"type"`
> File string `yaml:"file"`
> } `yaml:"format"`
> }
>
> const invalidYaml = `
>  namespace: 
> name: bbb
> description: c
> format::
>   type: sample
> file: foo.sh
> `
>
> func main() {
> fmt.Println(invalidYaml)
> sample := &Sample{}
> err := yaml.Unmarshal([]byte(invalidYaml), sample)
> fmt.Printf("%v\n", err)
> }
>
> The result in mac is here
> % sw_vers; go version; git log --oneline -1; go run main.go
> (git)-[master]
> ProductName:Mac OS X
> ProductVersion: 10.12.6
> BuildVersion:   16G1036
> go version go1.10 darwin/amd64
> 201773b (HEAD -> master, origin/master, origin/HEAD) add line break
>
>  namespace: 
> name: bbb
> description: c
> format::
>   type: sample
> file: foo.sh
>
> yaml: line 2: did not find expected 
>
> The result in linux is here
> cat /proc/version; go version; git log --oneline -1; go run main.go
> Linux version 3.10.0-693.11.6.el7.x86_64 (buil...@kbuilder.dev.centos.org)
> (gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) ) #1 SMP Thu Jan 4
> 01:06:37 UTC 2018
> go version go1.10 linux/amd64
> 201773b add line break
>
>  namespace: 
> name: bbb
> description: c
> format::
>   type: sample
> file: foo.sh
>
> 
>
> Am I answer collect?
>
> Thank you.
> Yuichi
>
> --
> 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 options, visit https://groups.google.com/d/optout.

-- 
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 options, visit https://groups.google.com/d/optout.

Re: [go-nuts] About 64bits alignment

[T L]

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 makes 64-bit words 64-bit aligned on i386 OSes." 
> >> 
> >> AFAIK, that's not the case, ie. not always. 
> >> 
> >> -- 
> >> 
> >> -j 
> > 
> > 
> > But it looks the results from Go playground (which is a 32-bit OS env) 
> > show all 64-bit words are 64-bit aligned on 32-bit OS. 
> > 
> > https://play.golang.org/p/J2TT4yskRQT 
>
> The playground currently runs in the amd64p32 environment, which is to 
> say with a 64-bit CPU with 32-bit pointers.  This is done in order to 
> use NativeClient as a sandbox technology.  Try running your program on 
> real hardware with GOARCH=386. 
>
> Ian 
>

Thanks for the clarification. 

-- 
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 options, visit https://groups.google.com/d/optout.

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

[T L]

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 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 options, visit https://groups.google.com/d/optout.

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

[Jan Mercl]

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 
"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 options, visit https://groups.google.com/d/optout.

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

[T L]

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
>
>
> -- 
>
> -j
>

yes, alias works.

Just realize that this is not a "append" specified question.
I feel the following one should be also valid.

package main

import "fmt"

func main() {
s := []int{1, 2, 3}
fmt.Println(s...)
}

 

-- 
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 options, visit https://groups.google.com/d/optout.

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

['Axel Wagner' via golang-nuts]

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 become that: https://play.golang.org/p/nY-BB3t0IAw
>>
>>
>> --
>>
>> -j
>>
>
> yes, alias works.
>
> Just realize that this is not a "append" specified question.
> I feel the following one should be also valid.
>

This is the same question of why you can't convert `[]int` to
`[]interface{}` - it's a costly operation and Go tends to not hide
expensive operations from you.


>
> package main
>
> import "fmt"
>
> func main() {
> s := []int{1, 2, 3}
> fmt.Println(s...)
> }
>
>
>
> --
> 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 options, visit https://groups.google.com/d/optout.
>

-- 
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 options, visit https://groups.google.com/d/optout.

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

[Yuichi Sawada]

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 Peppe 
Date:   Tue Jan 9 11:43:31 2018 +

Merge pull request #253 from heldtogether/patch-1

docs: note need for public struct fields

 In Linux I use
commit 7f97868eec74b32b0982dd158a51a446d1da7eb5
Merge: 3e6d767 49fdd64
Author: Roger Peppe 
Date:   Fri Feb 23 19:12:37 2018 +

Merge pull request #336 from rogpeppe/025-go.mod


Really sorry for I am not checking these things and send message and very 
thank you for your help.
If I meet these thing, firstly I try to create same environments.

Thank you
Yuichi

-- 
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 options, visit https://groups.google.com/d/optout.

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

[T L]

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 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
>>>
>>
>> yes, alias works.
>>
>> Just realize that this is not a "append" specified question.
>> I feel the following one should be also valid.
>>
>
> This is the same question of why you can't convert `[]int` to 
> `[]interface{}` - it's a costly operation and Go tends to not hide 
> expensive operations from you.
>

Yes. But I think there is a little specialty here.
It is a problem of which viewpoint is right.
1. fmt.Println(1, 2, 3) is a shorthand of fmt.Println([]interface{1, 2, 
3}...)
2. fmt.Println(aBlankInterfaceSlice...) is a shorthand of 
fmt.Println(aBlankInterfaceSlice[0], aBlankInterfaceSlice[1], ..., 
aBlankInterfaceSlice[N])
 

>  
>
>>
>> package main
>>
>> import "fmt"
>>
>> func main() {
>> s := []int{1, 2, 3}
>> fmt.Println(s...)
>> }
>>
>>  
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 options, visit https://groups.google.com/d/optout.

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

[T L]

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, 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

>>>
>>> yes, alias works.
>>>
>>> Just realize that this is not a "append" specified question.
>>> I feel the following one should be also valid.
>>>
>>
>> This is the same question of why you can't convert `[]int` to 
>> `[]interface{}` - it's a costly operation and Go tends to not hide 
>> expensive operations from you.
>>
>
> Yes. But I think there is a little specialty here.
> It is a problem of which viewpoint is right.
> 1. fmt.Println(1, 2, 3) is a shorthand of fmt.Println([]interface{1, 2, 
> 3}...)
> 2. fmt.Println(aBlankInterfaceSlice...) is a shorthand of 
> fmt.Println(aBlankInterfaceSlice[0], aBlankInterfaceSlice[1], ..., 
> aBlankInterfaceSlice[N])
>

Go spec does imply the first viewpoint is right.
 

>  
>
>>  
>>
>>>
>>> package main
>>>
>>> import "fmt"
>>>
>>> func main() {
>>> s := []int{1, 2, 3}
>>> fmt.Println(s...)
>>> }
>>>
>>>  
>>>
>>> -- 
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
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 options, visit https://groups.google.com/d/optout.