Re: [go-nuts] Unmarshalling and tags

[roger peppe]

I feel your pain - we quite often have tags with entries for three
formats (JSON, YAML and BSON) - but I'm not sure that collapsing them
is necessarily a good idea, as the named tags indicate that the object
is explicitly intended to be able to be marshaled with those formats.

That said, it's quite common for us to have an issue where someone has
(say) tagged for YAML but not for JSON.

Given that there is (more-or-less) a standard subset of the tags that
works between encodings, maybe it would make sense to have
a standard tag that could be used for all of them, similarly to the
way that TextUnmarshaler and TextMarshaler are supported across
most encodings.

For example:

type Payment struct {
ActionType paypal.ActionType `encode:"actionType,omitempty"`
ReceiverList paypal.ReceiverList `encode:"actionType,omitempty"`
}

One would need to define the format quite carefully,
and perhaps define things so that attributes not recognised
by a particular encoder are ignored (allowing, for example,
an XML-specific "attr" tag without preventing JSON
from using it)

Then of course every existing encoder would need to be updated
to recognise it...

  cheers,
rog.

On 19 June 2016 at 13:42, 'Mihai B' via golang-nuts
 wrote:
> Hi there,
>
> I have a struct that needs to be marshalled/unmarshalled using various
> serialization formats(xml, json, name/value). The tags start to represent a
> considerable effort[0] so I'm wondering if this is a common use case and if
> a change[1] to the encoding packages to specify the tag key/selectors would
> be a bad idea. Another option would be to use a standard tag key as default
> (e.g. "encoding") but I think it may violate  the Go1 backward
> compatibility.
>
> Mihai.
>
>
> [0]
> type Payment struct {
> ActionType paypal.ActionType `query:"actionType,omitempty"
> json:"actionType,omitempty"  xml:"actionType,omitempty"`
> ReceiverList paypal.ReceiverList `query:"actionType,omitempty"
> json:"receiverList,omitempty"  xml:"receiverList,omitempty"`
> }
>
>
> [1] (dec *Decoder)SetTagKey(key string)
>
> --
> 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] [?] emulating an opengl shader in cpu bound functions

[Christian Mauduit]

Hi,

Using OpenGL to draw something that will end up on paper might prove
somewhat complicated. As for "translating" a shader to something cpu
bound, since a shader is more or less a program in some language that
"has some remote parentness with C", you could probably do it. But the
most pragmatic way, IMHO, is to understand what the program does and
rewrite it. If you really want to leverage OpenGL's power, I know it
allows you to render "in memory" so you could draw things on a virtual
screen, grab the output, and you're set. To some extent, recent OpenGL
with shaders is more or less a generic way to harness the power of
massive parallel, dedicated hardware, and it's very versatile. But
complex as well.

If you are not a graphics guru, I'd advice you to use a plain simple
native Go library, there are several candidates, one is :

https://github.com/llgcode/draw2d/

Have a nice day,

Christian.

On 06/20/2016 05:02 PM, bluebl...@gmail.com wrote:
> 
> 
> 
> I am attempting to generate a random starfield, in go. This is something
> that will need to printed on actual paper, but that is another issue and
> I only mention it to give some context for what I am doing here: Using
> go to create graphics to pair with something I'm already doing in go
> (I've been through several iterations of trying to use the go parts I
> have with numerous variations of tex/latex templates using asymptote,
> and I reached a point of frustration where I figured why not just do it
> all in go, as it seems less a problem than I originally thought -- but
> opens a new set of problems to solve, one of the biggest is that I know
> nothing at all about graphics, let alone how to apply graphics in go).
> 
> Cosmic1 from: 
> https://gist.github.com/thrisp/1ed1785ac6a902585595fb8cb52f0a16,
> generates the above it is the first thing that even roughly approximates
> what I want to do.
> 
> Any thoughts, or help cleaning that up. Maybe tell me why exactly I
> can't directly translate an opengl shader to something cpu bound(which I
> suspect is a thing, I may need to do more that I can't see right now).
> 
> -- 
> 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.

-- 
Christian Mauduit
uf...@ufoot.org
http://www.ufoot.org
int q = (2 * b) || !(2 * b);

-- 
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: Result is sometimes different despite using same value when encode by encoding/gob

[Harry]

Thank Dave and Jan.

I understood completely.
I'd consider another solution to manage that next.

Thanks again.


Harry.


2016年6月21日火曜日 14時58分39秒 UTC+9 Dave Cheney:
>
> To serialise the keys and values of a map and code would have to iterate 
> over it
>
> for k,v := range m { 
>// serialise k and v
> }
>
> But map iteration does not have a guaranteed ordering. This is why the 
> result is not stable.
>
> On Tuesday, 21 June 2016 15:44:05 UTC+10, Harry wrote:
>>
>> Hello guys,
>>
>> I'm trying to use encoding/gob package to know how it works.
>> And I wrote below codes.
>>
>>
>>
>> import "encoding/gob"
>>
>>
>> func ToGOB64(data interface{}) (string, error) {
>>  b := bytes.Buffer{}
>>
>>  e := gob.NewEncoder(&b)
>>  err := e.Encode(data)
>>  if err != nil {
>>  fmt.Println(`failed gob Encode`, err)
>>  return "", err
>>  }
>>  return base64.StdEncoding.EncodeToString(b.Bytes()), nil
>>
>> }
>>
>>
>>
>> func FromGOB64(str string, tData interface{}) error {
>>
>>  by, err := base64.StdEncoding.DecodeString(str)
>>
>>  if err != nil {
>>  return err
>>
>>  }
>>  b := bytes.Buffer{}
>>  b.Write(by)
>>  d := gob.NewDecoder(&b)
>>  err = d.Decode(tData)
>>  if err != nil {
>>  return err
>>
>>  }
>>  return nil
>> }
>>
>>
>> And then, I prepared for test targeted type are struct, map, interface{}.
>>
>> func TestSerializeStruct(t *testing.T) {
>>  u := User{Id: 10, Name: "harry dayo"}
>>
>>  result, err := ToGOB64(u)
>>  if err != nil {
>>  t.Errorf("TestSerializeStruct error: %s", err)
>>  }
>>  if result != 
>> "Iv+BAwEBBFVzZXIB/4IAAQIBAklkAQQAAQROYW1lAQwR/4IBFAEKaGFycnkgZGF5bwA=" 
>> {
>>  t.Errorf("TestSerializeStruct result: %+v", result)
>>  }
>> }
>>
>>
>>
>> func TestDeSerializeStruct(t *testing.T) {
>>
>>
>>  u := User{}
>>  err := FromGOB64(
>> "Iv+BAwEBBFVzZXIB/4IAAQIBAklkAQQAAQROYW1lAQwR/4IBFAEKaGFycnkgZGF5bwA="
>> , &u)
>>  if err != nil {
>>  t.Errorf("TestDeSerializeStruct error: %s", err)
>>  }
>>  if u.Id != 10 {
>>  t.Errorf("TestDeSerializeStruct result: %+v", u)
>>  }
>> }
>>
>>
>> //2.map (map is not stable.)
>> func TestSerializeMap(t *testing.T) {
>>
>>
>>  m := map[string]int{"apple": 150, "banana": 300, "lemon": 300}
>>  //when using map, result is not stable.
>>  result, err := ToGOB64(m)
>>  if err != nil {
>>  t.Errorf("TestSerializeMap error: %s", err)
>>  }
>>  if result != 
>> "Dv+DBAEC/4QAAQwBBAAAIP+EAAMFYXBwbGX+ASwGYmFuYW5h/gJYBWxlbW9u/gJY" {
>>  //if result != 
>> "Dv+DBAEC/4QAAQwBBAAAIP+EAAMGYmFuYW5h/gJYBWxlbW9u/gJYBWFwcGxl/gEs" {
>>  t.Errorf("TestSerializeMap result: %#v", result)
>>  }
>> }
>>
>>
>> //
>> func TestDeSerializeMap(t *testing.T) {
>>
>>
>>  u := map[string]int{}
>>  
>> //FromGOB64("Dv+DBAEC/4QAAQwBBAAAIP+EAAMFYXBwbGX+ASwGYmFuYW5h/gJYBWxlbW9u/gJY",
>>  
>> &u)
>>  err := FromGOB64(
>> "Dv+DBAEC/4QAAQwBBAAAIP+EAAMGYmFuYW5h/gJYBWxlbW9u/gJYBWFwcGxl/gEs", &u)
>>  if err != nil {
>>  t.Errorf("TestDeSerializeMap error: %s", err)
>>  }
>>  if u["apple"] != 150 {
>>  t.Errorf("TestDeSerializeMap result: %#v", u)
>>  }
>> }
>>
>>
>>
>> //interface x slice
>> func TestSerializeInterfaces(t *testing.T) {
>>
>>
>>  args := []interface{}{1, "abcde", true}
>>  result, err := ToGOB64(args)
>>  if err != nil {
>>  t.Errorf("TestSerializeInterfaces error: %s", err)
>>  }
>>  if result != 
>> "DP+BAgEC/4IAARAAACX/ggADA2ludAQCAAIGc3RyaW5nDAcABWFiY2RlBGJvb2wCAgAB" {
>>  t.Errorf("TestSerializeInterfaces result: %+v", result)
>>  }
>> }
>>
>>
>>
>> func TestDeSerializeInterfaces(t *testing.T) {
>>
>>
>>  args := []interface{}{}
>>  err := FromGOB64(
>> "DP+BAgEC/4IAARAAACX/ggADA2ludAQCAAIGc3RyaW5nDAcABWFiY2RlBGJvb2wCAgAB", &
>> args)
>>  if err != nil {
>>  t.Errorf("TestDeSerializeInterfaces error: %s", err)
>>  }
>>  if args[0] != 1 || args[1] != "abcde" || args[2] != true {
>>  t.Errorf("TestDeSerializeInterfaces result: %+v", args)
>>  }
>> }
>>
>>
>>
>> As a result, serialized map value often change though deserialized map is 
>> no problem.
>> Why serialized value is not invaliable when using map value.
>>
>> I'd like to know that reason sincerely.
>>
>> Thanks in advance.
>>
>>
>>
>>
>>
>>

-- 
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] Result is sometimes different despite using same value when encode by encoding/gob

[Jan Mercl]

On Tue, Jun 21, 2016 at 7:44 AM Harry  wrote:

> Why serialized value is not invaliable when using map value.

Map keys are comparable but they are not required to be ordered
, ie. sorting them before
serializing is not only costly, but in the general case not (directly)
possible.

-- 

-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] Fedora and crypto/elliptic.P224

[as . utf8]

Security has little to do with this. It's a "legal" problem:

Unfortunately, this code has to be removed due to legal concerns. We 
> apologize for any inconvenience this causes you.


https://lists.stg.fedoraproject.org/archives/list/gol...@lists.fedoraproject.org/thread/RDAHDK4RKN477G2ZDSX4DZT5EDD4WVTX/

> So you're telling me that some random lawyer's decision is preventing me
> > from generating an SSH key required to do my job?
> > 
> > Classic.
> Short answer is yes. Btw you really should tell your deputy/senator your 
> opinion regarding software patents.

https://bugzilla.redhat.com/show_bug.cgi?id=319901


On Monday, June 20, 2016 at 10:24:46 PM UTC-7, Henrik Johansson wrote:
>
> The second one,  the redhat Bugzilla does. They only want to ship a select 
> set of curves distro wide apparently. If it is motivated by security or 
> something else is less clear. 
>
> On Tue, Jun 21, 2016, 07:08 Ian Lance Taylor  > wrote:
>
>> On Mon, Jun 20, 2016 at 9:18 PM,  > 
>> wrote:
>> >
>> > Nothing is stopping them, but people aren't going to go to the 
>> distribution
>> > docs for the Go standard library - they're going to go to the official 
>> docs.
>>
>> It  is not sustainable for us to provide distro-specific docs for
>> changes made by distros.  They need to provide their own docs.  That
>> is unfortunate but I don't see any other workable approach.
>>
>> A better strategy here would be for them to come to us and ask us to
>> make the change and explain why it is appropriate.  The links you
>> provided do not explain it.
>>
>> 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...@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: Result is sometimes different despite using same value when encode by encoding/gob

[Dave Cheney]

To serialise the keys and values of a map and code would have to iterate 
over it

for k,v := range m { 
   // serialise k and v
}

But map iteration does not have a guaranteed ordering. This is why the 
result is not stable.

On Tuesday, 21 June 2016 15:44:05 UTC+10, Harry wrote:
>
> Hello guys,
>
> I'm trying to use encoding/gob package to know how it works.
> And I wrote below codes.
>
>
>
> import "encoding/gob"
>
>
> func ToGOB64(data interface{}) (string, error) {
>  b := bytes.Buffer{}
>
>  e := gob.NewEncoder(&b)
>  err := e.Encode(data)
>  if err != nil {
>  fmt.Println(`failed gob Encode`, err)
>  return "", err
>  }
>  return base64.StdEncoding.EncodeToString(b.Bytes()), nil
>
> }
>
>
>
> func FromGOB64(str string, tData interface{}) error {
>
>  by, err := base64.StdEncoding.DecodeString(str)
>
>  if err != nil {
>  return err
>
>  }
>  b := bytes.Buffer{}
>  b.Write(by)
>  d := gob.NewDecoder(&b)
>  err = d.Decode(tData)
>  if err != nil {
>  return err
>
>  }
>  return nil
> }
>
>
> And then, I prepared for test targeted type are struct, map, interface{}.
>
> func TestSerializeStruct(t *testing.T) {
>  u := User{Id: 10, Name: "harry dayo"}
>
>  result, err := ToGOB64(u)
>  if err != nil {
>  t.Errorf("TestSerializeStruct error: %s", err)
>  }
>  if result != 
> "Iv+BAwEBBFVzZXIB/4IAAQIBAklkAQQAAQROYW1lAQwR/4IBFAEKaGFycnkgZGF5bwA=" 
> {
>  t.Errorf("TestSerializeStruct result: %+v", result)
>  }
> }
>
>
>
> func TestDeSerializeStruct(t *testing.T) {
>
>
>  u := User{}
>  err := FromGOB64(
> "Iv+BAwEBBFVzZXIB/4IAAQIBAklkAQQAAQROYW1lAQwR/4IBFAEKaGFycnkgZGF5bwA="
> , &u)
>  if err != nil {
>  t.Errorf("TestDeSerializeStruct error: %s", err)
>  }
>  if u.Id != 10 {
>  t.Errorf("TestDeSerializeStruct result: %+v", u)
>  }
> }
>
>
> //2.map (map is not stable.)
> func TestSerializeMap(t *testing.T) {
>
>
>  m := map[string]int{"apple": 150, "banana": 300, "lemon": 300}
>  //when using map, result is not stable.
>  result, err := ToGOB64(m)
>  if err != nil {
>  t.Errorf("TestSerializeMap error: %s", err)
>  }
>  if result != 
> "Dv+DBAEC/4QAAQwBBAAAIP+EAAMFYXBwbGX+ASwGYmFuYW5h/gJYBWxlbW9u/gJY" {
>  //if result != 
> "Dv+DBAEC/4QAAQwBBAAAIP+EAAMGYmFuYW5h/gJYBWxlbW9u/gJYBWFwcGxl/gEs" {
>  t.Errorf("TestSerializeMap result: %#v", result)
>  }
> }
>
>
> //
> func TestDeSerializeMap(t *testing.T) {
>
>
>  u := map[string]int{}
>  
> //FromGOB64("Dv+DBAEC/4QAAQwBBAAAIP+EAAMFYXBwbGX+ASwGYmFuYW5h/gJYBWxlbW9u/gJY",
>  
> &u)
>  err := FromGOB64(
> "Dv+DBAEC/4QAAQwBBAAAIP+EAAMGYmFuYW5h/gJYBWxlbW9u/gJYBWFwcGxl/gEs", &u)
>  if err != nil {
>  t.Errorf("TestDeSerializeMap error: %s", err)
>  }
>  if u["apple"] != 150 {
>  t.Errorf("TestDeSerializeMap result: %#v", u)
>  }
> }
>
>
>
> //interface x slice
> func TestSerializeInterfaces(t *testing.T) {
>
>
>  args := []interface{}{1, "abcde", true}
>  result, err := ToGOB64(args)
>  if err != nil {
>  t.Errorf("TestSerializeInterfaces error: %s", err)
>  }
>  if result != 
> "DP+BAgEC/4IAARAAACX/ggADA2ludAQCAAIGc3RyaW5nDAcABWFiY2RlBGJvb2wCAgAB" {
>  t.Errorf("TestSerializeInterfaces result: %+v", result)
>  }
> }
>
>
>
> func TestDeSerializeInterfaces(t *testing.T) {
>
>
>  args := []interface{}{}
>  err := FromGOB64(
> "DP+BAgEC/4IAARAAACX/ggADA2ludAQCAAIGc3RyaW5nDAcABWFiY2RlBGJvb2wCAgAB", &
> args)
>  if err != nil {
>  t.Errorf("TestDeSerializeInterfaces error: %s", err)
>  }
>  if args[0] != 1 || args[1] != "abcde" || args[2] != true {
>  t.Errorf("TestDeSerializeInterfaces result: %+v", args)
>  }
> }
>
>
>
> As a result, serialized map value often change though deserialized map is 
> no problem.
> Why serialized value is not invaliable when using map value.
>
> I'd like to know that reason sincerely.
>
> Thanks in advance.
>
>
>
>
>
>

-- 
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] Result is sometimes different despite using same value when encode by encoding/gob

[Harry]

Hello guys,

I'm trying to use encoding/gob package to know how it works.
And I wrote below codes.



import "encoding/gob"


func ToGOB64(data interface{}) (string, error) {
 b := bytes.Buffer{}

 e := gob.NewEncoder(&b)
 err := e.Encode(data)
 if err != nil {
 fmt.Println(`failed gob Encode`, err)
 return "", err
 }
 return base64.StdEncoding.EncodeToString(b.Bytes()), nil

}



func FromGOB64(str string, tData interface{}) error {

 by, err := base64.StdEncoding.DecodeString(str)

 if err != nil {
 return err

 }
 b := bytes.Buffer{}
 b.Write(by)
 d := gob.NewDecoder(&b)
 err = d.Decode(tData)
 if err != nil {
 return err

 }
 return nil
}


And then, I prepared for test targeted type are struct, map, interface{}.

func TestSerializeStruct(t *testing.T) {
 u := User{Id: 10, Name: "harry dayo"}

 result, err := ToGOB64(u)
 if err != nil {
 t.Errorf("TestSerializeStruct error: %s", err)
 }
 if result != 
"Iv+BAwEBBFVzZXIB/4IAAQIBAklkAQQAAQROYW1lAQwR/4IBFAEKaGFycnkgZGF5bwA=" {
 t.Errorf("TestSerializeStruct result: %+v", result)
 }
}



func TestDeSerializeStruct(t *testing.T) {


 u := User{}
 err := FromGOB64(
"Iv+BAwEBBFVzZXIB/4IAAQIBAklkAQQAAQROYW1lAQwR/4IBFAEKaGFycnkgZGF5bwA=", 
&u)
 if err != nil {
 t.Errorf("TestDeSerializeStruct error: %s", err)
 }
 if u.Id != 10 {
 t.Errorf("TestDeSerializeStruct result: %+v", u)
 }
}


//2.map (map is not stable.)
func TestSerializeMap(t *testing.T) {


 m := map[string]int{"apple": 150, "banana": 300, "lemon": 300}
 //when using map, result is not stable.
 result, err := ToGOB64(m)
 if err != nil {
 t.Errorf("TestSerializeMap error: %s", err)
 }
 if result != 
"Dv+DBAEC/4QAAQwBBAAAIP+EAAMFYXBwbGX+ASwGYmFuYW5h/gJYBWxlbW9u/gJY" {
 //if result != 
"Dv+DBAEC/4QAAQwBBAAAIP+EAAMGYmFuYW5h/gJYBWxlbW9u/gJYBWFwcGxl/gEs" {
 t.Errorf("TestSerializeMap result: %#v", result)
 }
}


//
func TestDeSerializeMap(t *testing.T) {


 u := map[string]int{}
 
//FromGOB64("Dv+DBAEC/4QAAQwBBAAAIP+EAAMFYXBwbGX+ASwGYmFuYW5h/gJYBWxlbW9u/gJY", 
&u)
 err := FromGOB64(
"Dv+DBAEC/4QAAQwBBAAAIP+EAAMGYmFuYW5h/gJYBWxlbW9u/gJYBWFwcGxl/gEs", &u)
 if err != nil {
 t.Errorf("TestDeSerializeMap error: %s", err)
 }
 if u["apple"] != 150 {
 t.Errorf("TestDeSerializeMap result: %#v", u)
 }
}



//interface x slice
func TestSerializeInterfaces(t *testing.T) {


 args := []interface{}{1, "abcde", true}
 result, err := ToGOB64(args)
 if err != nil {
 t.Errorf("TestSerializeInterfaces error: %s", err)
 }
 if result != 
"DP+BAgEC/4IAARAAACX/ggADA2ludAQCAAIGc3RyaW5nDAcABWFiY2RlBGJvb2wCAgAB" {
 t.Errorf("TestSerializeInterfaces result: %+v", result)
 }
}



func TestDeSerializeInterfaces(t *testing.T) {


 args := []interface{}{}
 err := FromGOB64(
"DP+BAgEC/4IAARAAACX/ggADA2ludAQCAAIGc3RyaW5nDAcABWFiY2RlBGJvb2wCAgAB", &
args)
 if err != nil {
 t.Errorf("TestDeSerializeInterfaces error: %s", err)
 }
 if args[0] != 1 || args[1] != "abcde" || args[2] != true {
 t.Errorf("TestDeSerializeInterfaces result: %+v", args)
 }
}



As a result, serialized map value often change though deserialized map is 
no problem.
Why serialized value is not invaliable when using map value.

I'd like to know that reason sincerely.

Thanks in advance.





-- 
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] Fedora and crypto/elliptic.P224

[Henrik Johansson]

The second one,  the redhat Bugzilla does. They only want to ship a select
set of curves distro wide apparently. If it is motivated by security or
something else is less clear.

On Tue, Jun 21, 2016, 07:08 Ian Lance Taylor  wrote:

> On Mon, Jun 20, 2016 at 9:18 PM,   wrote:
> >
> > Nothing is stopping them, but people aren't going to go to the
> distribution
> > docs for the Go standard library - they're going to go to the official
> docs.
>
> It  is not sustainable for us to provide distro-specific docs for
> changes made by distros.  They need to provide their own docs.  That
> is unfortunate but I don't see any other workable approach.
>
> A better strategy here would be for them to come to us and ask us to
> make the change and explain why it is appropriate.  The links you
> provided do not explain it.
>
> 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.
>

-- 
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] Fedora and crypto/elliptic.P224

[Ian Lance Taylor]

On Mon, Jun 20, 2016 at 9:18 PM,   wrote:
>
> Nothing is stopping them, but people aren't going to go to the distribution
> docs for the Go standard library - they're going to go to the official docs.

It  is not sustainable for us to provide distro-specific docs for
changes made by distros.  They need to provide their own docs.  That
is unfortunate but I don't see any other workable approach.

A better strategy here would be for them to come to us and ask us to
make the change and explain why it is appropriate.  The links you
provided do not explain it.

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] Fedora and crypto/elliptic.P224

[as . utf8]

   Go should not encourage distribution builder shenanigans. The effective 
way to solve this problem is by submitting it as an issue to the 
appropriate community it affects. A high search rank will accumulate based 
on the popularity of this issue, and the feedback (blame) will flow to the 
right channels accordingly.

One can argue that Fedora users won't know that the curve is unsupported, 
and would not even realize that the problem is Fedora specific, but this is 
a weak argument for a system that doesn't have standard facilities for 
decoding mp3 files.

On Monday, June 20, 2016 at 9:18:13 PM UTC-7, Josh Chase wrote:
>
> Nothing is stopping them, but people aren't going to go to the 
> distribution docs for the Go standard library - they're going to go to the 
> official docs. 
>
> On Monday, June 20, 2016 at 9:13:18 PM UTC-7, as@gmail.com wrote:
>>
>> If the distribution builders can take it out, what is preventing them 
>> from adding their own documentation?
>>
>> On Monday, June 20, 2016 at 9:06:26 PM UTC-7, Joshua Chase wrote:
>>>
>>> Yep, that's exactly what I'm saying.
>>>
>>>
>>> https://lists.stg.fedoraproject.org/archives/list/gol...@lists.fedoraproject.org/thread/ZLKQK7BOBVQVZ5B2ACQSXCOAOKLVRSTL/
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1038683
>>>
>>> Supposedly patent/legal reasons?
>>>
>>>
>>> On Mon, Jun 20, 2016 at 9:03 PM, Ian Lance Taylor  
>>> wrote:
>>>
 On Mon, Jun 20, 2016 at 6:59 PM,   wrote:
 >
 > Should there be a note in the documentation that this has been 
 removed by
 > the Fedora packagers?
 >
 > It would help assure developers that they're not insane when they get 
 a
 > compile error claiming that something that
 > https://golang.org/pkg/crypto/elliptic says should be there, isn't 
 there.

 I'm not sure I understand: are you saying that Fedora removed
 crypto/elliptic.P224 when they packaged the Go distribution?  Why
 would they do that?

 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] golang.org/x/text/transform.Chain is not thread safe

[Ian Lance Taylor]

On Mon, Jun 20, 2016 at 9:15 PM,   wrote:
> I am guessing the same efficiency should be possible. Except, each call to a
> chained Transform
> would involve a couple of allocations (to create the state). On the good
> side, this simplifies concurrent
> code sharing the same object (no locks), avoids the original problem
> (concurrency corruption) and avoid
> having to create multiple instances of the same chain if one is to avoid
> locks (saves allocations here).

Unfortunately, a couple of allocations is not the same efficiency.

That said, this is mpvl's code and he would make the final decision.

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] Fedora and crypto/elliptic.P224

[jcjoshuachase]

Nothing is stopping them, but people aren't going to go to the distribution 
docs for the Go standard library - they're going to go to the official 
docs. 

On Monday, June 20, 2016 at 9:13:18 PM UTC-7, as@gmail.com wrote:
>
> If the distribution builders can take it out, what is preventing them from 
> adding their own documentation?
>
> On Monday, June 20, 2016 at 9:06:26 PM UTC-7, Joshua Chase wrote:
>>
>> Yep, that's exactly what I'm saying.
>>
>>
>> https://lists.stg.fedoraproject.org/archives/list/gol...@lists.fedoraproject.org/thread/ZLKQK7BOBVQVZ5B2ACQSXCOAOKLVRSTL/
>> https://bugzilla.redhat.com/show_bug.cgi?id=1038683
>>
>> Supposedly patent/legal reasons?
>>
>>
>> On Mon, Jun 20, 2016 at 9:03 PM, Ian Lance Taylor  
>> wrote:
>>
>>> On Mon, Jun 20, 2016 at 6:59 PM,   wrote:
>>> >
>>> > Should there be a note in the documentation that this has been removed 
>>> by
>>> > the Fedora packagers?
>>> >
>>> > It would help assure developers that they're not insane when they get a
>>> > compile error claiming that something that
>>> > https://golang.org/pkg/crypto/elliptic says should be there, isn't 
>>> there.
>>>
>>> I'm not sure I understand: are you saying that Fedora removed
>>> crypto/elliptic.P224 when they packaged the Go distribution?  Why
>>> would they do that?
>>>
>>> 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] golang.org/x/text/transform.Chain is not thread safe

[alkemir]

I am guessing the same efficiency should be possible. Except, each call to 
a chained Transform
would involve a couple of allocations (to create the state). On the good 
side, this simplifies concurrent
code sharing the same object (no locks), avoids the original problem 
(concurrency corruption) and avoid
having to create multiple instances of the same chain if one is to avoid 
locks (saves allocations here).

 

> The general rule for the standard library is that if a type does not 
> explicitly say that it is safe to call methods from multiple 
> goroutines, then it is not safe to do so.  That said, it may be 
> reasonable to explicitly state that in this case.
>

I agree, but consider the Forms used in my example above, they are 
thread-safe as they are package level
values.
 

>
> I don't think it should be made thread-safe unless the result is just 
> as efficient.  Efficiency matters here. 
>
> Ian 
>


Then I guess it is worth the try? I will have a proposal this weekend.

Regards

Bryan 

-- 
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] Fedora and crypto/elliptic.P224

[as . utf8]

If the distribution builders can take it out, what is preventing them from 
adding their own documentation?

On Monday, June 20, 2016 at 9:06:26 PM UTC-7, Joshua Chase wrote:
>
> Yep, that's exactly what I'm saying.
>
>
> https://lists.stg.fedoraproject.org/archives/list/gol...@lists.fedoraproject.org/thread/ZLKQK7BOBVQVZ5B2ACQSXCOAOKLVRSTL/
> https://bugzilla.redhat.com/show_bug.cgi?id=1038683
>
> Supposedly patent/legal reasons?
>
>
> On Mon, Jun 20, 2016 at 9:03 PM, Ian Lance Taylor  > wrote:
>
>> On Mon, Jun 20, 2016 at 6:59 PM,  > 
>> wrote:
>> >
>> > Should there be a note in the documentation that this has been removed 
>> by
>> > the Fedora packagers?
>> >
>> > It would help assure developers that they're not insane when they get a
>> > compile error claiming that something that
>> > https://golang.org/pkg/crypto/elliptic says should be there, isn't 
>> there.
>>
>> I'm not sure I understand: are you saying that Fedora removed
>> crypto/elliptic.P224 when they packaged the Go distribution?  Why
>> would they do that?
>>
>> Ian
>>
>
>
>
> -- 
> -Josh
> (502) 209-9704
>

-- 
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] Fedora and crypto/elliptic.P224

[Joshua Chase]

Yep, that's exactly what I'm saying.

https://lists.stg.fedoraproject.org/archives/list/gol...@lists.fedoraproject.org/thread/ZLKQK7BOBVQVZ5B2ACQSXCOAOKLVRSTL/
https://bugzilla.redhat.com/show_bug.cgi?id=1038683

Supposedly patent/legal reasons?


On Mon, Jun 20, 2016 at 9:03 PM, Ian Lance Taylor  wrote:

> On Mon, Jun 20, 2016 at 6:59 PM,   wrote:
> >
> > Should there be a note in the documentation that this has been removed by
> > the Fedora packagers?
> >
> > It would help assure developers that they're not insane when they get a
> > compile error claiming that something that
> > https://golang.org/pkg/crypto/elliptic says should be there, isn't
> there.
>
> I'm not sure I understand: are you saying that Fedora removed
> crypto/elliptic.P224 when they packaged the Go distribution?  Why
> would they do that?
>
> Ian
>



-- 
-Josh
(502) 209-9704

-- 
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: Example for using JWT with SermoDigital/jose/jws

[macmillan . josh09]

Thanks Scott. Even after changing it to RS256 I get the same error.

On Monday, June 20, 2016 at 7:14:10 PM UTC-7, macmilla...@gmail.com wrote:
>
> I get this error 'Error serializing the key. json: error calling 
> MarshalJSON for type jws.Claims: unexpected end of JSON input'
> I believe that I need to find the function that sign the token. The docs 
> don't have any usage exampl - 
> https://godoc.org/github.com/SermoDigital/jose/jws
>
>  Any working example would be appreciated. 
>
> Thank you
>
> package main
>
> import (
> "fmt"
> "io/ioutil"
> "log"
> "os"
> )
>
> import "github.com/SermoDigital/jose/jws"
>
> const (
> privKeyPath = "keys/app.rsa" // openssl genrsa -out keys/app.rsa 1024
> pubKeyPath  = "keys/app.rsa.pub" // openssl rsa -in keys/app.rsa -pubout 
> > keys/app.rsa.pub
> )
>
> var signKey []byte
>
> func init() {
> var err error
> signKey, err = ioutil.ReadFile(privKeyPath)
> if err != nil {
> log.Fatal("Error reading private key")
> os.Exit(1)
> }
>
> }
>
> func main() {
> token := createJWT()
> fmt.Println("Created token", token)
> }
>
> func createJWT() string {
> claims := jws.Claims{}
> // claims.Set("AccessToken", "level1")
> signMethod := jws.GetSigningMethod("HS512")
> token := jws.NewJWT(claims, signMethod)
> byteToken, err := token.Serialize(signKey)
> if err != nil {
> log.Fatal("Error signing the key. ", err)
> os.Exit(1)
> }
>
> return string(byteToken)
> }
>
>

-- 
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] Fedora and crypto/elliptic.P224

[Ian Lance Taylor]

On Mon, Jun 20, 2016 at 6:59 PM,   wrote:
>
> Should there be a note in the documentation that this has been removed by
> the Fedora packagers?
>
> It would help assure developers that they're not insane when they get a
> compile error claiming that something that
> https://golang.org/pkg/crypto/elliptic says should be there, isn't there.

I'm not sure I understand: are you saying that Fedora removed
crypto/elliptic.P224 when they packaged the Go distribution?  Why
would they do that?

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] net.ListenUDP, ListenTCP & new go routine creation

[Ian Lance Taylor]

On Mon, Jun 20, 2016 at 8:09 PM, Matt Harden  wrote:
> OK, wait. You mentioned namespaces. It is definitely not supported in any
> way to have different threads or goroutines running in different namespaces
> within a single Go process. The Go scheduler can move a goroutine from one
> thread to another at any time and it is not aware of namespaces. In fact,
> anything that causes different threads to run in different contexts is not
> supported and cannot work reliably in Go.

Yes.

I want to add that you are asking about goroutines but it seems that
what you actually care about are threads.  The Go scheduler will
automatically create a new thread when an existing thread blocks in a
system call.  The Go program has no control over when or how new
threads are created, or which existing thread is used to create a new
thread.

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.

[go-nuts] Re: Example for using JWT with SermoDigital/jose/jws

[Scott]

You're loading in an RSA key but signing with HS512, try changing:

signMethod := jws.GetSigningMethod("HS512")


to

signMethod := jws.GetSigningMethod("RS256")




On Monday, June 20, 2016 at 10:14:10 PM UTC-4, macmilla...@gmail.com wrote:
>
> I get this error 'Error serializing the key. json: error calling 
> MarshalJSON for type jws.Claims: unexpected end of JSON input'
> I believe that I need to find the function that sign the token. The docs 
> don't have any usage exampl - 
> https://godoc.org/github.com/SermoDigital/jose/jws
>
>  Any working example would be appreciated. 
>
> Thank you
>
> package main
>
> import (
> "fmt"
> "io/ioutil"
> "log"
> "os"
> )
>
> import "github.com/SermoDigital/jose/jws"
>
> const (
> privKeyPath = "keys/app.rsa" // openssl genrsa -out keys/app.rsa 1024
> pubKeyPath  = "keys/app.rsa.pub" // openssl rsa -in keys/app.rsa -pubout 
> > keys/app.rsa.pub
> )
>
> var signKey []byte
>
> func init() {
> var err error
> signKey, err = ioutil.ReadFile(privKeyPath)
> if err != nil {
> log.Fatal("Error reading private key")
> os.Exit(1)
> }
>
> }
>
> func main() {
> token := createJWT()
> fmt.Println("Created token", token)
> }
>
> func createJWT() string {
> claims := jws.Claims{}
> // claims.Set("AccessToken", "level1")
> signMethod := jws.GetSigningMethod("HS512")
> token := jws.NewJWT(claims, signMethod)
> byteToken, err := token.Serialize(signKey)
> if err != nil {
> log.Fatal("Error signing the key. ", err)
> os.Exit(1)
> }
>
> return string(byteToken)
> }
>
>

-- 
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] golang.org/x/text/transform.Chain is not thread safe

[Ian Lance Taylor]

On Mon, Jun 20, 2016 at 5:57 PM, Bryan Reynaert  wrote:
>
> the following code panics with: runtime error: slice bounds out of range
>
>
> var testTransform = transform.Chain(norm.NFD, norm.NFC)
>
> func main() {
> for i := 0; i < 200; i++ {
> go func() {
> transform.String(testTransform, "nonemptystring")
> }()
> }
> time.Sleep(time.Second)
> }
>
> The reason is transform.Chain returns a Transformer which keeps an internal
> state
> while sequentially applying each transformation. When called by two
> goroutines,
> this state gets corrupted.
>
> For me, this was unexpected, as each transform by itself seems thread-safe.
> Errors
> caused by this behaviour might be hard to track. I suggest changing the
> implementation
> of transform.Chain.Transform to generate a new state for each call or make a
> note about
> this in the docs.
>
> Or maybe I was expecting something I should not?
>
> I can write a thread-safe version of chain.Transform if this is the way to
> go. Please comment.

The general rule for the standard library is that if a type does not
explicitly say that it is safe to call methods from multiple
goroutines, then it is not safe to do so.  That said, it may be
reasonable to explicitly state that in this case.

I don't think it should be made thread-safe unless the result is just
as efficient.  Efficiency matters here.

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.

[go-nuts] Fedora and crypto/elliptic.P224

[jcjoshuachase]

Should there be a note in the documentation that this has been removed by 
the Fedora packagers?

It would help assure developers that they're not insane when they get a 
compile error claiming that something that 
https://golang.org/pkg/crypto/elliptic says should be there, isn't there.

-- 
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] net.ListenUDP, ListenTCP & new go routine creation

[Matt Harden]

OK, wait. You mentioned namespaces. It is definitely not supported in any
way to have different threads or goroutines running in different namespaces
within a single Go process. The Go scheduler can move a goroutine from one
thread to another at any time and it is not aware of namespaces. In fact,
anything that causes different threads to run in different contexts is not
supported and cannot work reliably in Go.

On Mon, Jun 20, 2016 at 8:04 PM Matt Harden  wrote:

> Nothing about using the network requires new goroutine creation. I
> wouldn't expect Dial to create new goroutines, except perhaps temporarily
> during DNS lookup or something.
>
> On Mon, Jun 20, 2016 at 6:38 PM Manohar Kumar 
> wrote:
>
>>
>>
>> On Monday, June 20, 2016 at 9:31:08 AM UTC-7, Ian Lance Taylor wrote:
>>
>>> On Sat, Jun 18, 2016 at 10:17 PM, Manohar Kumar 
>>> wrote:
>>> >
>>> > Is it possible that a net.ListenTCP or  ListenUDP call can result in
>>> new go
>>> > routine/OS thread creation ? I guess not all system calls result in a
>>> new go
>>> > routine (and OS thread if necessary) creation. But ListenTCP & UDP
>>> does many
>>> > things underneath and its not clear if it can lead to new go routine
>>> > creation.
>>>
>>> ListenTCP and ListenUDP will not create new goroutines or threads.
>>> But those calls just create new listeners; you probably meant to ask
>>> about the AcceptTCP and ReadFrom/WriteTo methods.  Those methods will
>>> not normally create new goroutines.  However, they may block, and that
>>> may cause the Go runtime to create a new thread.
>>>
>>
>> Thanks. How about Dial()  ? Since Dial to a TCP destination requires a
>> connection to be established I think it can lead to new go routine
>> creation. Can that happen for Dial to an UDP destination as well (which
>> shouldn't trigger any network transaction)?
>>
>> This code runs on a root network namespace and some other child network
>> namespaces.  Its not a desirable behavior to have new OS created while its
>> executing in the child namespaces.
>>
>> -Manohar.
>>
>>
>>> > I am mainly interested in Linux and have to make these calls in a part
>>> of
>>> > the code where new OS thread creation isn't desirable. Please note
>>> that
>>> > changing that aspect of the design itself is not an option for me.
>>>
>>> The Go runtime is free to create new OS threads at any time.  You can
>>> not reasonably use Go under the restrictions you describe.
>>>
>>> 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.
>>
>

-- 
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] net.ListenUDP, ListenTCP & new go routine creation

[Matt Harden]

Nothing about using the network requires new goroutine creation. I wouldn't
expect Dial to create new goroutines, except perhaps temporarily during DNS
lookup or something.

On Mon, Jun 20, 2016 at 6:38 PM Manohar Kumar 
wrote:

>
>
> On Monday, June 20, 2016 at 9:31:08 AM UTC-7, Ian Lance Taylor wrote:
>
>> On Sat, Jun 18, 2016 at 10:17 PM, Manohar Kumar 
>> wrote:
>> >
>> > Is it possible that a net.ListenTCP or  ListenUDP call can result in
>> new go
>> > routine/OS thread creation ? I guess not all system calls result in a
>> new go
>> > routine (and OS thread if necessary) creation. But ListenTCP & UDP does
>> many
>> > things underneath and its not clear if it can lead to new go routine
>> > creation.
>>
>> ListenTCP and ListenUDP will not create new goroutines or threads.
>> But those calls just create new listeners; you probably meant to ask
>> about the AcceptTCP and ReadFrom/WriteTo methods.  Those methods will
>> not normally create new goroutines.  However, they may block, and that
>> may cause the Go runtime to create a new thread.
>>
>
> Thanks. How about Dial()  ? Since Dial to a TCP destination requires a
> connection to be established I think it can lead to new go routine
> creation. Can that happen for Dial to an UDP destination as well (which
> shouldn't trigger any network transaction)?
>
> This code runs on a root network namespace and some other child network
> namespaces.  Its not a desirable behavior to have new OS created while its
> executing in the child namespaces.
>
> -Manohar.
>
>
>> > I am mainly interested in Linux and have to make these calls in a part
>> of
>> > the code where new OS thread creation isn't desirable. Please note that
>> > changing that aspect of the design itself is not an option for me.
>>
>> The Go runtime is free to create new OS threads at any time.  You can
>> not reasonably use Go under the restrictions you describe.
>>
>> 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.
>

-- 
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] Example for using JWT with SermoDigital/jose/jws

[macmillan . josh09]

I get this error 'Error serializing the key. json: error calling 
MarshalJSON for type jws.Claims: unexpected end of JSON input'
I believe that I need to find the function that sign the token. The docs 
don't have any usage exampl 
- https://godoc.org/github.com/SermoDigital/jose/jws

 Any working example would be appreciated. 

Thank you

package main

import (
"fmt"
"io/ioutil"
"log"
"os"
)

import "github.com/SermoDigital/jose/jws"

const (
privKeyPath = "keys/app.rsa" // openssl genrsa -out keys/app.rsa 1024
pubKeyPath  = "keys/app.rsa.pub" // openssl rsa -in keys/app.rsa -pubout > 
keys/app.rsa.pub
)

var signKey []byte

func init() {
var err error
signKey, err = ioutil.ReadFile(privKeyPath)
if err != nil {
log.Fatal("Error reading private key")
os.Exit(1)
}

}

func main() {
token := createJWT()
fmt.Println("Created token", token)
}

func createJWT() string {
claims := jws.Claims{}
// claims.Set("AccessToken", "level1")
signMethod := jws.GetSigningMethod("HS512")
token := jws.NewJWT(claims, signMethod)
byteToken, err := token.Serialize(signKey)
if err != nil {
log.Fatal("Error signing the key. ", err)
os.Exit(1)
}

return string(byteToken)
}

-- 
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] Re: Is there a bug in path.Dir?

[Ian Lance Taylor]

On Mon, Jun 20, 2016 at 5:59 PM,  <18126523...@163.com> wrote:
> Package "filepath" works well, but the "path" package is not recommended ?

The path package is for slash-separated packages such as appear in URLs.

The path/filepath package is for paths in the file system.

Ian


> 在 2016年6月20日星期一 UTC+8下午1:40:55，徐新华写道：
>>
>> Package path implements utility routines for manipulating
>> slash-separated(/) paths.
>>
>> So, you should use "path/filepath"
>
> --
> 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] golang.org/x/text/transform.Chain is not thread safe

[Bryan Reynaert]

Dear all,

the following code panics with: runtime error: slice bounds out of range


var testTransform = transform.Chain(norm.NFD, norm.NFC)

func main() {
for i := 0; i < 200; i++ {
go func() {
transform.String(testTransform, "nonemptystring")
}()
}
time.Sleep(time.Second)
}

The reason is transform.Chain returns a Transformer which keeps an internal 
state
while sequentially applying each transformation. When called by two 
goroutines,
this state gets corrupted.

For me, this was unexpected, as each transform by itself seems thread-safe. 
Errors
caused by this behaviour might be hard to track. I suggest changing the 
implementation
of transform.Chain.Transform to generate a new state for each call or make 
a note about
this in the docs.

Or maybe I was expecting something I should not?

I can write a thread-safe version of chain.Transform if this is the way to 
go. Please comment.

Regards

Bryan

-- 
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] [ANN] primegen.go: Sieve of Atkin prime number generator

[gordonbgood]

On Monday, June 20, 2016 at 6:33:29 AM UTC-7, gordo...@gmail.com wrote:
Further to the subject of compiler efficiency, the following is the assembler 
code output with array bounds checking turned off (-B) the the inner tight 
composite culling loop of FasterEratspeed above (generated with go tool compile 
-B -S FasterEratspeed.go > FasterEratspeed.asm): 

0x0051 00081 (main.go:426)MOVLR11, CX 
0x0054 00084 (main.go:426)SHRL$5, R11 
0x0058 00088 (main.go:428)MOVL(R9)(R11*4), R13 
0x005c 00092 (main.go:430)MOVL$1, R14 
0x0062 00098 (main.go:430)SHLLCX, R14 
0x0065 00101 (main.go:430)ORLR13, R14 
0x0068 00104 (main.go:431)MOVLR14, (R9)(R11*4) 
0x006c 00108 (main.go:429)LEAL(R12)(CX*1), R11 
0x0070 00112 (main.go:425)CMPLR11, R8 
0x0073 00115 (main.go:425)JCS$0, 81 

At 10 instructions, this is about as tight as it gets other than for using the 
more complex read/modify/write version of the ORL instruction, but that doesn't 
seem to save much if any time given instruction latencies.  Note that this code 
has eliminated the "k & 31" for the shift, seeming to recognize that it isn't 
necessary as a long shift can't be greater than 31

Getting rid of the &31 is easy and I'll do that in 1.8.
 
anyway, that unlike the simple PrimeSpeed program, this properly uses the 
immediate load of '1',

I don't know what the issue is yet, but it shouldn't be hard to fix in 1.8.
 
that it cleverly uses the LEAL instruction to add the prime value 'q' in R12 to 
the unmodified 'k' value in CX to produce the sum to the original location of 
'j' in R11 to save another instruction to move the results from CX to R11. 

The current SSA backend should do this also.
 
No, Keith, you seem to have misunderstood, I wasn't complaining above the above 
assembler codeas produced by the 1.7beta1 compiler, and I was wondering why it 
always isn't this good, which is about as good as it gets for this loop and 
already properly gets rid of &31, does a proper immediate load of 1, and the 
clever use of the LEA instruction without the misuse of the LEA instruction to 
continuously recalculate 'p'.  The assembler code above is produced by either 
of the below loop variations:

1) as it is in FasterEratspeed:

for k < lngthb {
pos := k >> 5
data := k & 31
bits := buf[pos]
k += q
bits |= 1 << data // two[data]
buf[pos] = bits
}

2) I get the same assembler code if I change this to the simpler:

for ; k < lngthb; k += q {
buf[k>>5] |= 1 << (k & 31)
}

where all variables and buffers are uint32.

My question was, why did the compiler produce this very good code for both 
variations, yet produced something much worse for the same variation two loop 
in the simple PrimeSpeed code, with the main difference that PrimeSpeed uses 
64-bit uint for the loop variables and loop limit.  Does that give you a clue 
where the problem might be?  Converting PrimeSpeed to use uint32's as here 
fixed the continuous recalculation of 'p' but not the other problems.

It seems that sometimes the compiler erroneously tries to reduce register use 
without applying the cost in execution speed to the decision.  It is 
inconsistent, sometimes producing great code as here, and sometimes not so 
great as in PrimeSpeed.

I was looking for some general advice on how to format loops so they produce 
code as good as this?

Do you plan to include SSA for the x86 version as well?

-- 
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] [ANN] primegen.go: Sieve of Atkin prime number generator

[gordonbgood]

On Monday, June 20, 2016 at 6:33:29 AM UTC-7, gordo...@gmail.com wrote:
Further to the subject of compiler efficiency, the following is the assembler 
code output with array bounds checking turned off (-B) the the inner tight 
composite culling loop of FasterEratspeed above (generated with go tool compile 
-B -S FasterEratspeed.go > FasterEratspeed.asm): 

0x0051 00081 (main.go:426)MOVLR11, CX 
0x0054 00084 (main.go:426)SHRL$5, R11 
0x0058 00088 (main.go:428)MOVL(R9)(R11*4), R13 
0x005c 00092 (main.go:430)MOVL$1, R14 
0x0062 00098 (main.go:430)SHLLCX, R14 
0x0065 00101 (main.go:430)ORLR13, R14 
0x0068 00104 (main.go:431)MOVLR14, (R9)(R11*4) 
0x006c 00108 (main.go:429)LEAL(R12)(CX*1), R11 
0x0070 00112 (main.go:425)CMPLR11, R8 
0x0073 00115 (main.go:425)JCS$0, 81 

At 10 instructions, this is about as tight as it gets other than for using the 
more complex read/modify/write version of the ORL instruction, but that doesn't 
seem to save much if any time given instruction latencies.  Note that this code 
has eliminated the "k & 31" for the shift, seeming to recognize that it isn't 
necessary as a long shift can't be greater than 31

Getting rid of the &31 is easy and I'll do that in 1.8.
 
anyway, that unlike the simple PrimeSpeed program, this properly uses the 
immediate load of '1',

I don't know what the issue is yet, but it shouldn't be hard to fix in 1.8.
 
that it cleverly uses the LEAL instruction to add the prime value 'q' in R12 to 
the unmodified 'k' value in CX to produce the sum to the original location of 
'j' in R11 to save another instruction to move the results from CX to R11. 

The current SSA backend should do this also.
 
No, Keith, you seem to have misunderstood, I wasn't complaining above the above 
assembler codeas produced by the 1.7beta1 compiler, and I was wondering why it 
always isn't this good, which is about as good as it gets for this loop and 
already properly gets rid of &31, does a proper immediate load of 1, and the 
clever use of the LEA instruction without the misuse of the LEA instruction to 
continuously recalculate 'p'.  The assembler code above is produced by either 
of the below loop variations:

1) as it is in FasterEratspeed:

for k < lngthb {
pos := k >> 5
data := k & 31
bits := buf[pos]
k += q
bits |= 1 << data // two[data]
buf[pos] = bits
}

2) I get the same assembler code if I change this to the simpler:

for ; k < lngthb; k += q {
buf[k>>5] |= 1 << (k & 31)
}

where all variables and buffers are uint32.

My question was, why did the compiler produce this very good code for both 
variations, yet produced something much worse for the same variation two loop 
in the simple PrimeSpeed code, with the main difference that PrimeSpeed uses 
64-bit uint for the loop variables and loop limit.  Does that give you a clue 
where the problem might be?  Converting PrimeSpeed to use uint32's as here 
fixed the continuous recalculation of 'p' but not the other problems.

It seems that sometimes the compiler erroneously tries to reduce register use 
without applying the cost in execution speed to the decision.  It is 
inconsistent, sometimes producing great code as here, and sometimes not so 
great as in PrimeSpeed.

I was looking for some general advice on how to format loops so they produce 
code as good as this?

Do you plan to include SSA for the x86 version as well?

-- 
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] net.ListenUDP, ListenTCP & new go routine creation

[Manohar Kumar]

On Monday, June 20, 2016 at 9:31:08 AM UTC-7, Ian Lance Taylor wrote:
>
> On Sat, Jun 18, 2016 at 10:17 PM, Manohar Kumar  > wrote: 
> > 
> > Is it possible that a net.ListenTCP or  ListenUDP call can result in new 
> go 
> > routine/OS thread creation ? I guess not all system calls result in a 
> new go 
> > routine (and OS thread if necessary) creation. But ListenTCP & UDP does 
> many 
> > things underneath and its not clear if it can lead to new go routine 
> > creation. 
>
> ListenTCP and ListenUDP will not create new goroutines or threads. 
> But those calls just create new listeners; you probably meant to ask 
> about the AcceptTCP and ReadFrom/WriteTo methods.  Those methods will 
> not normally create new goroutines.  However, they may block, and that 
> may cause the Go runtime to create a new thread. 
>

Thanks. How about Dial()  ? Since Dial to a TCP destination requires a 
connection to be established I think it can lead to new go routine 
creation. Can that happen for Dial to an UDP destination as well (which 
shouldn't trigger any network transaction)?

This code runs on a root network namespace and some other child network 
namespaces.  Its not a desirable behavior to have new OS created while its 
executing in the child namespaces.

-Manohar.


> > I am mainly interested in Linux and have to make these calls in a part 
> of 
> > the code where new OS thread creation isn't desirable. Please note that 
> > changing that aspect of the design itself is not an option for me. 
>
> The Go runtime is free to create new OS threads at any time.  You can 
> not reasonably use Go under the restrictions you describe. 
>
> 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.

[go-nuts] Re: Is there a bug in path.Dir?

[18126523585]

Package "filepath" works well, but the "path" package is not recommended ?

在 2016年6月20日星期一 UTC+8下午1:40:55，徐新华写道：
>
> Package path implements utility routines for manipulating 
> slash-separated(/) paths.
>
> So, you should use "path/filepath"
>

-- 
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: A proposal for generic in go

[xingtao zhao]

That was my original thought. While later I realized that we still need 
some parameter check in the callee code to satisfy the interface matching 
(the generic version of each function in my proposal). And we need special 
assembler function for dynamic interface cast.

On Monday, June 20, 2016 at 1:34:15 PM UTC-7, andrew...@gmail.com wrote:
>
> Overhead at runtime will be not very big;
> 1. Generate each time an instance of specific generic type with arguments
> 2. Perform generic specific type checks before any kind of an assignements
>
> 1. The first overhead can be reduced (eleminated) by the static code 
> generation of specified generic types with storing them in special place
>
> Eg.
>
> foo := Foo{}
>
> Since this code is static (which means that at runtime the arguments 
> (string and int) remains unchanged then this type (Foo) can 
> be canonicalized (I can also say "hashed" but canonicalized is more 
> precisely). pre-generated by the compiler and stored (to avoid re-creating 
> it each time at runtime) for further use.
>
> 2. The second overhead can be reduced (eleminated) by the static code 
> generation when compiler can compute types (used in assignments).
>
> Since specific generic type is know at compile time then generic type 
> checks (the same as regular, non generic) can be performed at compile time
>

-- 
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] A proposal for generic in go

[Rodrigo Kochenburger]

Micky, I'm not sure where you're quoting from but they never said it's
never gonna happen.

>From the FAQ: "Generics may well be added at some point." and "This remains
an open issue".

https://golang.org/doc/faq#generics


On Mon, Jun 20, 2016 at 4:54 PM Micky  wrote:

> It's never going to happen! To quote the powers-to-be, "The language is
> done".
> Good luck!
>
> On Wed, Jun 15, 2016 at 6:04 AM, xingtao zhao 
> wrote:
> > Here is my proposal for generic in go:
> >
> https://docs.google.com/document/d/1nO7D15c2B3eq2kF62C0yUs_UgpkyPL2zHhMAmlq1l98/edit?usp=sharing
> >
> > Many parts has not been finished, and just initial thoughts. In the
> > proposal, I want to keep back compatibility. And I try to add the
> orthogonal
> > feature only and keep the language still simple enough.
> >
> > Please add your comments on it. Hope it is useful and could inspire some
> new
> > features in go 2.0
> >
> > 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.
>

-- 
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] A proposal for generic in go

[Micky]

It's never going to happen! To quote the powers-to-be, "The language is done".
Good luck!

On Wed, Jun 15, 2016 at 6:04 AM, xingtao zhao  wrote:
> Here is my proposal for generic in go:
> https://docs.google.com/document/d/1nO7D15c2B3eq2kF62C0yUs_UgpkyPL2zHhMAmlq1l98/edit?usp=sharing
>
> Many parts has not been finished, and just initial thoughts. In the
> proposal, I want to keep back compatibility. And I try to add the orthogonal
> feature only and keep the language still simple enough.
>
> Please add your comments on it. Hope it is useful and could inspire some new
> features in go 2.0
>
> 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.

[go-nuts] Re: Discussion on "Vendoring edge case, critical problem"

[Dave Cheney]

On Tuesday, 21 June 2016 00:42:54 UTC+10, Chad wrote:
>
> But if you vendor, you don't really need type equality do you?
>

That sounds like a lot to give up.
 

> Maybe it's a design flaw when types or interfaces with unexported methods 
> from the vendored pkg are visible to the end user of the vendoring pkg.
>

I think any solution that meant code behaved differently depending on where 
it was on disk during compilation should be looked at with deep suspicion.
 

>
> On Sunday, June 19, 2016 at 10:52:34 PM UTC+2, Dave Cheney wrote:
>>
>> If you mean forking their dependencies and rewiring their import paths, 
>> that is a possibility. But it leaves consumers of those packages in the 
>> same position as the thread the OP referenced because the same code is now 
>> known by two distinct import paths breaking type equality. 
>
>

-- 
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] Re: Currying in Go

[Tyler Compton]

Thank you, Jesper, that's very interesting.

On Sunday, June 19, 2016 at 8:15:13 AM UTC-7, Jesper Louis Andersen wrote:
>
>
> On Sat, Jun 18, 2016 at 5:32 AM, Tyler Compton  > wrote:
>
>> I don't pretend to be proficient in this realm of functional programming, 
>> but I would be very surprised if this is valuable in a language like Go 
>> that can and does hold state.
>
>
> In functional languages, it is often used as a way to "configure" a 
> function. I.e., the function is defined as 
>
> let f conf x = ...
>
> where 'f' is the function name, 'conf' a parameter of configuration and 
> 'x' the "real" argument to the function. Now, partial application such a (f 
> c) for some configuration 'c', yields another function which has been 
> configured, or specialized, to the particular use case.
>
> Usually it allows you to define a generic function and then specialize it 
> in some context by "plugging in" a configuration. The configuration is 
> often a constant value which means the compiler will typically 
> constant-propagate that value into the closure. Many functional compilers 
> understand that closures with static data can be eliminated at compile time 
> by replacing them with a normal function. In other words, you have a 
> generic variant of your function, but when run it is specialized and 
> instantiated into an optimized variant.
>
> You *can* get the same with a function such as 'f(conf, x)' but in this 
> case, the compiler usually has some more work to do before it can apply the 
> above transformation.
>
>
>
> -- 
> 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.

[go-nuts] Re: A proposal for generic in go

[andrew . mezoni]

Overhead at runtime will be not very big;
1. Generate each time an instance of specific generic type with arguments
2. Perform generic specific type checks before any kind of an assignements

1. The first overhead can be reduced (eleminated) by the static code 
generation of specified generic types with storing them in special place

Eg.

foo := Foo{}

Since this code is static (which means that at runtime the arguments 
(string and int) remains unchanged then this type (Foo) can 
be canonicalized (I can also say "hashed" but canonicalized is more 
precisely). pre-generated by the compiler and stored (to avoid re-creating 
it each time at runtime) for further use.

2. The second overhead can be reduced (eleminated) by the static code 
generation when compiler can compute types (used in assignments).

Since specific generic type is know at compile time then generic type 
checks (the same as regular, non generic) can be performed at compile time

-- 
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: A proposal for generic in go

[andrew . mezoni]

As for me then everything is much more simple if Go language (as the 
starting point) will  introduce a non-reified generics.
Non reified generics does not requires a complex runtime support (static 
code which was generated by the compiler will be enough).
Type checking of the type arguments performed at the compile time on the 
calller side (sender code).
The callee side (receiver code) remains unchanged as it is currently is.
This has some benefits:
1. This is a starting point (but not a no dead end) and point for a later 
enhancements
2. Does not requires significant changes in the compiler (codegen)
3. Does not requires significant changes in the runtime (engine)
4. Does not requires significant changes in the type system (just to add a 
few additional fields into the interface type presentation)
5. Does not requires significant changes in the reflection (just to adapt 
for slightly extended type presentation)

Because they (generic types) will be not reified on the callee side 
(receiver code) then compiler can generate the same code as it generates 
currently.
Only callers side will perform generic type checks before assignments of 
values with generic types and vice versa (to variables, constants, function 
and methods arguments).

That is.

type Foo struct {
}

func (s *Foo) Get(key K) (val V) {
  // Here is generated unchanged code
  // The same as for non generic use
}

func some() {
  foo := Foo{}

  // Generated by the compiler
  // _typ := _getRTypeOf(foo)
  // _typ.isGeneric = true
  // _typ.genParams = [2]_GenParam
  // _typ.genParams[0] = &_GenParam{key: "K", val: _getRType(interface{}}
  // _typ.genParams[0] = &_GenParam{key: "V", val: _getRType(interface{}}
  // _typ.genArgs = [2]*_RType{}
  // _typ.genArgs[0] = _getRType(string)
  // _typ.genArgs[1] = _getRType(int)
  // Also compiler statically performs type check bounds of the type 
arguments to type parameters assignments (if type bounds specified)

  var key interface{}
  key = bool

  // Generated by the compiler (safe guard)
  // _temp0 := key
  // _checkGenericArg(_typ, 0, temp0)
  // _temp1 := foo.Get(key)

  val := foo.Get(_temp0)
}

That is, the compiler always (if it cannot compute the type at compile time 
and cannot to check them statically) inserts "safe guards" type check 
before any kimd of an assignments.
The `_checkGenericArg(_typ, index, key)` also performs the checks to type 
parameter bounds (eg. for Foo) for a given index of the 
type parameter and argument.

Callee code does not performs any type checks on incomming parameters.
It always think that incomming parameters has specified type.
That is, if type bounds ommitted then specified type is interface{}
If type bounds specified then specified type is itself

Eg.

type Type1 struct {
}

type Type2 struct {
}

func(t *Type1) foo(val E) {
}

func(t *Type2) foo(val E) {
}

Generated as the following (that's easy)

func(t *Type1) foo(val interface{}) {
}

func(t *Type2) foo(val int) {
}

-- 
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] Unmarshalling and tags

[Jakob Borg]

2016-06-19 12:42 GMT+02:00 'Mihai B' via golang-nuts
:
> I have a struct that needs to be marshalled/unmarshalled using various
> serialization formats(xml, json, name/value). The tags start to represent a
> considerable effort[0] so I'm wondering if this is a common use case and if
> a change[1] to the encoding packages to specify the tag key/selectors would
> be a bad idea. Another option would be to use a standard tag key as default
> (e.g. "encoding") but I think it may violate  the Go1 backward
> compatibility.
>
> Mihai.
>
>
> [0]
> type Payment struct {
> ActionType paypal.ActionType `query:"actionType,omitempty"
> json:"actionType,omitempty"  xml:"actionType,omitempty"`
> ReceiverList paypal.ReceiverList `query:"actionType,omitempty"
> json:"receiverList,omitempty"  xml:"receiverList,omitempty"`
> }

For what it's worth, in cases where I've needed to do this the tags
have often differed for the various formats.

type SomeOptions struct {
   ...
   AlwaysLocalNets   []string `xml:"alwaysLocalNet"
json:"alwaysLocalNets"`
   DeprecatedUPnPEnabled bool `xml:"upnpEnabled,omitempty" json:"-"`
   ...
}

For slices, the plural case differs as you want "items": ["foo",
"bar"] in JSON but foobar in XML. The
deprecated option should be read from the XML source but omitted in
the JSON response. And so on.

//jb

-- 
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] Is there any overhead to casting a pointer (or uintptr) to and from unsafe.Pointer? Can uintptr be safely used to reference an object?

[Jason E. Aten]

On Mon, Jun 20, 2016 at 1:08 PM, Ian Lance Taylor  wrote:

> On Mon, Jun 20, 2016 at 10:39 AM, Jason E. Aten 
> wrote:
> > This does raise an interesting question: how should one detect cycles in
> a
> > graph of Go objects, in a garbage-collection safe manner?
> >
> > I am using reflect.ValueOf(x).Pointer() at the moment (which gives an
> > uintptr), but this seem vulnerable to having the garbage collector move
> the
> > object in the middle of my graph traversal.
>
> Instead of converting the pointer to a uintptr, just store the pointer
> itself in a map[interface{}]bool.  If you encounter the same pointer
> again, you will get the same map entry.  The GC must guarantee that
> using pointers as map keys will work even if the pointers move.
>
> Ian
>

Brilliant! Thank you, 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] Is there any overhead to casting a pointer (or uintptr) to and from unsafe.Pointer? Can uintptr be safely used to reference an object?

[Ian Lance Taylor]

On Mon, Jun 20, 2016 at 10:39 AM, Jason E. Aten  wrote:
> This does raise an interesting question: how should one detect cycles in a
> graph of Go objects, in a garbage-collection safe manner?
>
> I am using reflect.ValueOf(x).Pointer() at the moment (which gives an
> uintptr), but this seem vulnerable to having the garbage collector move the
> object in the middle of my graph traversal.

Instead of converting the pointer to a uintptr, just store the pointer
itself in a map[interface{}]bool.  If you encounter the same pointer
again, you will get the same map entry.  The GC must guarantee that
using pointers as map keys will work even if the pointers move.

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] Unmarshalling and tags

[Ian Lance Taylor]

On Sun, Jun 19, 2016 at 3:42 AM, 'Mihai B' via golang-nuts
 wrote:
>
> I have a struct that needs to be marshalled/unmarshalled using various
> serialization formats(xml, json, name/value). The tags start to represent a
> considerable effort[0] so I'm wondering if this is a common use case and if
> a change[1] to the encoding packages to specify the tag key/selectors would
> be a bad idea. Another option would be to use a standard tag key as default
> (e.g. "encoding") but I think it may violate  the Go1 backward
> compatibility.
>
> Mihai.
>
>
> [0]
> type Payment struct {
> ActionType paypal.ActionType `query:"actionType,omitempty"
> json:"actionType,omitempty"  xml:"actionType,omitempty"`
> ReceiverList paypal.ReceiverList `query:"actionType,omitempty"
> json:"receiverList,omitempty"  xml:"receiverList,omitempty"`
> }
>
>
> [1] (dec *Decoder)SetTagKey(key string)

I could be wrong but to me this sounds like a special case problem.  I
don't think many people are going to run into cases where they need to
specify omitEmpty for multiple encoding formats.  I'm certainly not
opposed to simplification here, but I don't see how to simplify
matters without making the code more complex or harder to use for the
normal case.

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] Is there any overhead to casting a pointer (or uintptr) to and from unsafe.Pointer? Can uintptr be safely used to reference an object?

[Jason E. Aten]

This does raise an interesting question: how should one detect cycles in a 
graph of Go objects, in a garbage-collection safe manner?

I am using reflect.ValueOf(x).Pointer() at the moment (which gives an 
uintptr), but this seem vulnerable to having the garbage collector move the 
object in the middle of my graph traversal.

-- 
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] KW Go Developers - First meetup August 9

[Cameron . Smith]

Hi everyone,

I would like to announce the first meetup of the KW Go Developers group in 
Waterloo, Canada.  The first meeting's topic is "Why Go?".  We'll discuss 
the problems that new languages such as Go, Rust, and Swift are trying to 
solve and why we settled on Go for some of our new development.   We'll be 
meeting on August 9 at 7pm.  You can find out more here:
http://www.meetup.com/Golang-KW/

Regards,

Cameron

-- 
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] WebAssembly as a target

[Ian Lance Taylor]

On Sat, Jun 18, 2016 at 11:16 PM, 'Mihai B' via golang-nuts
 wrote:
> I don't think we can expect anything before wasm supports GC (i.e. Phase 3 on 
> wasm roadmap). Once GC is supported(not very soon) Go could be compiled 
> through llgo[0]. One issue could be the binary size(.i.e due /reflect)

Go is also going to need some sort coroutine support.  I don't know
what WebAssembly provides in that area.

I think Go support for WebAssembly would be cool but I'm not aware of
anybody working on it.

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.

[go-nuts] Re: better understanding of * and & in go

[andrew . mezoni]

In Go arguments (function parameters) passed by value.
This means that when you call function you pass copy of the instances.
If you modify (received copy) then original instance remains unchanged.
Pointer points to the  storage of the instance.
When you pass pointer as an argument then you pass a copy of reference.
This means that you cannot change the strorage of the instance because you 
get a copy of the reference to the storage.
But this means that you can change the instance because you get reference 
of it storage.
You even can replace strored instance by the another instance.

-- 
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] Is there any overhead to casting a pointer (or uintptr) to and from unsafe.Pointer? Can uintptr be safely used to reference an object?

[andrew . mezoni]

>> Keeping a a pointer in a uintptr as a "reference" to something is safe 
iff it will never be casted back to a pointer. I think this means that the 
safe case is useless.

Storing any reference (read: address) of Go instance is unsafe because 
after when this operation ends then a stored address (as the uintptr value) 
can become not legal because any instance can be moved by GC into the other 
place (read: address).
This is a reason why recommended to perform such operation inside a sigle 
expression.

Eg.

VALID
e := unsafe.Pointer(uintptr(unsafe.Pointer(&x))

NOT VALID
addr := uintptr(unsafe.Pointer(&x)
e := unsafe.Pointer(addr)

Explained
addr := uintptr(unsafe.Pointer(&x)
// Here stored `addr` already can be non valid
e := unsafe.Pointer(addr)

-- 
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] better understanding of * and & in go

[Shawn Milochik]

 Here's a short video I made. I hope this helps explain it:
https://www.youtube.com/watch?v=hMSYabOnA3M

-- 
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] Is there any overhead to casting a pointer (or uintptr) to and from unsafe.Pointer? Can uintptr be safely used to reference an object?

[Kyle Stanly]

Thank you for re-opening and answering the question. The original reason 
why I closed it was because after looking it up in the unsafe package 
documentation (as I was skimming through source-code originally) it states 
in Section 2, Paragraph 4  (I feel 
like a lawyer stating it this way), that:

"A uintptr is an integer, not a reference. Converting a Pointer to a 
uintptr creates an integer value with no pointer semantics. Even if a 
uintptr holds the address of some object, the garbage collector will not 
update that uintptr's value if the object moves, nor will that uintptr keep 
the object from being reclaimed."

However, the whole issue of casting being handled at compile-time is 
comforting, as there shouldn't be any overhead whatsoever to the runtime.

On Monday, June 20, 2016 at 12:15:07 PM UTC-4, Jan Mercl wrote:
>
> On Mon, Jun 20, 2016 at 5:45 PM Kyle Stanly  > wrote:
>
> The GC is precise, it will not confuse an integer and a pointer.
>
> Keeping a a pointer in a uintptr as a "reference" to something is safe iff 
> it will never be casted back to a pointer. I think this means that the safe 
> case is useless.
>
> > Finally, is there any implicit overhead from casting to and from a 
> uintptr (and unsafe.Pointer)? 
>
> There are no casts in Go. Converting between a uintptr and a 
> unsafe.Pointer is a compile time typechecking issue, it has no runtime cost 
> - provided crashing one's machine is not considered a runtime "cost" ;-)
>
>
> -- 
>
> -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] better understanding of * and & in go

[Konstantin Khomoutov]

On Mon, 20 Jun 2016 09:28:05 -0700 (PDT)
JM  wrote:

> Can someone answer the question below in the first comment of the 
> ChangeRefValue function?  Also can anyone provide better explanations
> of waht's going on here, or a link that explains? Thanks.

Could you start with, say, [1]?

I think we absolutely can explain you how your function works but
really heaps of literature have been written on pointers so I urge you
to read something on this subject and then extrapolate that information
on Go.

Please note that it's better to drop the usage of the word "reference"
when you're dealing with pointers because it's reserved for special
types in Go which have the so-called reference semantics: channels,
maps and slices.

1. https://en.wikipedia.org/wiki/Pointer_%28computer_programming%29

-- 
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] net.ListenUDP, ListenTCP & new go routine creation

[Ian Lance Taylor]

On Sat, Jun 18, 2016 at 10:17 PM, Manohar Kumar  wrote:
>
> Is it possible that a net.ListenTCP or  ListenUDP call can result in new go
> routine/OS thread creation ? I guess not all system calls result in a new go
> routine (and OS thread if necessary) creation. But ListenTCP & UDP does many
> things underneath and its not clear if it can lead to new go routine
> creation.

ListenTCP and ListenUDP will not create new goroutines or threads.
But those calls just create new listeners; you probably meant to ask
about the AcceptTCP and ReadFrom/WriteTo methods.  Those methods will
not normally create new goroutines.  However, they may block, and that
may cause the Go runtime to create a new thread.

> I am mainly interested in Linux and have to make these calls in a part of
> the code where new OS thread creation isn't desirable. Please note that
> changing that aspect of the design itself is not an option for me.

The Go runtime is free to create new OS threads at any time.  You can
not reasonably use Go under the restrictions you describe.

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.

[go-nuts] better understanding of * and & in go

[JM]

Can someone answer the question below in the first comment of the 
ChangeRefValue function?  Also can anyone provide better explanations of 
waht's going on here, or a link that explains? Thanks.


playground version:
https://play.golang.org/p/8dYdYoL0WI


package main

import "fmt"

func main() {
a := 50.50 //sets the value in the created memory space to 
fmt.Println("Value of a is", a)
fmt.Println("Addres space of a is", &a)
ChangeRefValue(&a) //passing the memory address (pointer) to func
fmt.Println("Value of a after func call is", a)

}

//ChangeRefValue test function
func ChangeRefValue(a *float64) { //why does it need to be passed in as a * 
?
*a = 99.25  //adding a 
* to the a converts it a value so we can change it globally
fmt.Println("Value of *a in func after update is", *a)  //print the 
value from the memory space location
fmt.Println("Memory space of a in func after update is", a) //print the 
memory space address
}

-- 
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] [ANN] primegen.go: Sieve of Atkin prime number generator

['Keith Randall' via golang-nuts]

On Monday, June 20, 2016 at 6:33:29 AM UTC-7, gordo...@gmail.com wrote:
>
> Further to the subject of compiler efficiency, the following is the 
> assembler code output with array bounds checking turned off (-B) the the 
> inner tight composite culling loop of FasterEratspeed above (generated with 
> go tool compile -B -S FasterEratspeed.go > FasterEratspeed.asm): 
>
> 0x0051 00081 (main.go:426)MOVLR11, CX 
> 0x0054 00084 (main.go:426)SHRL$5, R11 
> 0x0058 00088 (main.go:428)MOVL(R9)(R11*4), R13 
> 0x005c 00092 (main.go:430)MOVL$1, R14 
> 0x0062 00098 (main.go:430)SHLLCX, R14 
> 0x0065 00101 (main.go:430)ORLR13, R14 
> 0x0068 00104 (main.go:431)MOVLR14, (R9)(R11*4) 
> 0x006c 00108 (main.go:429)LEAL(R12)(CX*1), R11 
> 0x0070 00112 (main.go:425)CMPLR11, R8 
> 0x0073 00115 (main.go:425)JCS$0, 81 
>
> At 10 instructions, this is about as tight as it gets other than for using 
> the more complex read/modify/write version of the ORL instruction, but that 
> doesn't seem to save much if any time given instruction latencies.  Note 
> that this code has eliminated the "k & 31" for the shift, seeming to 
> recognize that it isn't necessary as a long shift can't be greater than 31


Getting rid of the &31 is easy and I'll do that in 1.8.
 

> anyway, that unlike the simple PrimeSpeed program, this properly uses the 
> immediate load of '1',


I don't know what the issue is yet, but it shouldn't be hard to fix in 1.8.
 

> that it cleverly uses the LEAL instruction to add the prime value 'q' in 
> R12 to the unmodified 'k' value in CX to produce the sum to the original 
> location of 'j' in R11 to save another instruction to move the results from 
> CX to R11. 
>
>
The current SSA backend should do this also.
 

> This uses a total of 7 registers being CX, R8, R9, R11, R12, R13, and R14, 
> so it would be possible to make it work and run just as fast for x86 code. 
>  This includes one register to hold the prime value 'q' in R12, and one 
> register to hold the loop limit 'lngthb] in R8.  An array bounds check 
> requires another register to hold the array upper bound, which won't be 
> hard for x64 code, but will slow x86 code as there won't be enough 
> available registers unless the compiler can be made smart enough for 
> certain loop formats to recognize that the check isn't necessary, being 
> inherent to the loop check.  Pretty impressive if all loops could be 
> compiled as well as this, as this will run at very close to C/C++ speed! 
>
> When run within L1 cache on a modern Intel CPU without memory or execution 
> pipeline(s) bottle-necks, this code will run in about 3.5 CPU cycles per 
> loop or about 2.86 instructions per cycle. 
>
> I'm looking for the reason that this code is so efficient and the former 
> simple PrimeSpeed code was so poor; one clue might be that I used native 
> uint's and int's for PrimeSpeed, which are 64-bit on an amd version of the 
> compiler for that code so the code was using 'Q' suffix instructions that 
> perhaps it doesn't use as efficiently where uint32's and int32's are used 
> here. 
>
> Can the compiler guys contribute anything on how to format tight loop code 
> so it compiles as well as this?  If the crucial parts of the compiler and 
> libraries were written to compile to code as efficient as this, I don't 
> think anyone would ahve problems with golang's speed. 
>

-- 
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] Is there any overhead to casting a pointer (or uintptr) to and from unsafe.Pointer? Can uintptr be safely used to reference an object?

[Jan Mercl]

On Mon, Jun 20, 2016 at 5:45 PM Kyle Stanly  wrote:

The GC is precise, it will not confuse an integer and a pointer.

Keeping a a pointer in a uintptr as a "reference" to something is safe iff
it will never be casted back to a pointer. I think this means that the safe
case is useless.

> Finally, is there any implicit overhead from casting to and from a
uintptr (and unsafe.Pointer)?

There are no casts in Go. Converting between a uintptr and a unsafe.Pointer
is a compile time typechecking issue, it has no runtime cost - provided
crashing one's machine is not considered a runtime "cost" ;-)


-- 

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

[go-nuts] Re: Gomobile: Large .so/aar file size on Android

[nsajko]

Did you try the beta
 https://groups.google.com/forum/#!topic/golang-announce/ITzPaJnZGZw
?

It should be a lot better than go 1.6 at code elimination.

-- 
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: Gomobile: Large .so/aar file size on Android

[nsajko]

If it's still too much a bit can be saved on code size by disabling bounds 
checking.

-- 
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] Is there any overhead to casting a pointer (or uintptr) to and from unsafe.Pointer? Can uintptr be safely used to reference an object?

[Kyle Stanly]

I was just wondering about something right now. The original issue I 
thought using a uintptr would have over an unsafe.Pointer is because the 
Garbage Collector wouldn't associate it with an actual reference to an 
object and hence, if it was the the only reference to an object, it would 
get garbage collected. However, after recent digging, it turns out that the 
GC handles garbage collection (correct me if I am wrong, as I am making my 
argument/stance based on this "fact") by scanning slots for live-objects, 
wherein a slot is a pointer-size word-aligned contiguous region of memory 
in the heap. The GC maintains a bitmap to determine if an object is live by 
keeping 2-bits per slot and pretty much mapping them together. 

What I mean by this is... imagine you have the following memory layout...

[0xFF][0x32][0x03][0xA0] <- Pointer to some object
[0x00][0x00][0x00][0x20] <- Integer which happens to be same size as a 
pointer
[0xFF][0x32][0x03][0xA0] <- uintptr, the integer value of a pointer address
[0xFF][0x32][0x03][0xA1] <- Address of the object but with it's LSB 
marked/tagged

Does it determine whether or not an integer (such as a normal int, case 2, 
and a uintptr, case 3, and a tagged uintptr, case 4) points to an object as 
well to determine the liveliness of an object? 

Finally, is there any implicit overhead from casting to and from a uintptr 
(and unsafe.Pointer)?

-- 
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] [?] emulating an opengl shader in cpu bound functions

[blueblank]

I am attempting to generate a random starfield, in go. This is something 
that will need to printed on actual paper, but that is another issue and I 
only mention it to give some context for what I am doing here: Using go to 
create graphics to pair with something I'm already doing in go (I've been 
through several iterations of trying to use the go parts I have with 
numerous variations of tex/latex templates using asymptote, and I reached a 
point of frustration where I figured why not just do it all in go, as it 
seems less a problem than I originally thought -- but opens a new set of 
problems to solve, one of the biggest is that I know nothing at all about 
graphics, let alone how to apply graphics in go).

Cosmic1 from:  
https://gist.github.com/thrisp/1ed1785ac6a902585595fb8cb52f0a16, generates 
the above it is the first thing that even roughly approximates what I want 
to do.

Any thoughts, or help cleaning that up. Maybe tell me why exactly I can't 
directly translate an opengl shader to something cpu bound(which I suspect 
is a thing, I may need to do more that I can't see right now).

-- 
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] net.ListenUDP, ListenTCP & new go routine creation

[Jesse McNelis]

On 21 Jun 2016 12:42 a.m., "Manohar Kumar"  wrote:
>
> I am mainly interested in Linux and have to make these calls in a part of
the code where new OS thread creation isn't desirable. Please note that
changing that aspect of the design itself is not an option for me.

If you have a requirement that you need tight control over when threads are
created then Go isn't the language for you.

The net package makes a number of threads while it wait s on various
syscalls.

Can I ask why you need to avoid thread creation?

-- 
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] net.ListenUDP, ListenTCP & new go routine creation

[Manohar Kumar]

Hello,

Is it possible that a net.ListenTCP or  ListenUDP call can result in new go 
routine/OS thread creation ? I guess not all system calls result in a new 
go routine (and OS thread if necessary) creation. But ListenTCP & UDP does 
many things underneath and its not clear if it can lead to new go routine 
creation.

I am mainly interested in Linux and have to make these calls in a part of 
the code where new OS thread creation isn't desirable. Please note that 
changing that aspect of the design itself is not an option for me.

Manohar.

-- 
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] [ANN]: Unigornel: Clean-slate unikernels for Go

[henriverroken]

To all Go and unikernel enthousiasts,

We are happy to announce the [unigornel 
project](https://github.com/unigornel/unigornel) to the Go and unikernel 
community.

Unigornel is a clean-slate approach to unikernels for the Go programming 
language. It is built on Xen's Mini-OS and a fork of Go. Our goal is to 
build a library operating system predominantly written in Go, much like the 
MirageOS project.

The project is still in the development phase. Only basic hello world 
examples work. A network stack is in progress. It is already possible to 
build a unikernel that replies to ping echo requests. Currently the memory 
management system is the most lacking subsystem.

This project was part of a semester-long university project and we would 
now like to make it available to the general public. We welcome all 
contributions, remarks or questions.

To build your first unikernel, read [Getting 
Started](https://unigornel.org/doku.php?id=getting_started)!

Cheers,
Henri Verroken

-- 
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: Discussion on "Vendoring edge case, critical problem"

[Chad]

But if you vendor, you don't really need type equality do you?
Maybe it's a design flaw when types or interfaces with unexported methods 
from the vendored pkg are visible to the end user of the vendoring pkg.

On Sunday, June 19, 2016 at 10:52:34 PM UTC+2, Dave Cheney wrote:
>
> If you mean forking their dependencies and rewiring their import paths, 
> that is a possibility. But it leaves consumers of those packages in the 
> same position as the thread the OP referenced because the same code is now 
> known by two distinct import paths breaking type equality. 

-- 
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: Discussion on "Vendoring edge case, critical problem"

[contin673]

So, is the solution really two-part? 

The vendoring tools would display a warning when you vendor some code and then 
directly expose that type in your API, either as function parameters or as a 
return type, stating that this will make it harder to consume downstream.

Secondly, the user of the library gets some help by flattening the final vendor 
tree to latest vendored version of each lib.

-- 
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: Discussion on "Vendoring edge case, critical problem"

[Zellyn]

I made a proposal here 
, which 
seems to be generating generally positive discussion.

On Sunday, June 19, 2016 at 1:14:57 AM UTC-4, Tyler Compton wrote:
>
> A user brought up a problem with the current vendoring setup regarding 
> exposing types of a vendored dependency. There was a lot of great 
> discussion and it seemed like there was a consensus that something needed 
> to change, but I don't see that anything had come of it.
>
> Here is the discussion:
> https://groups.google.com/forum/#!topic/golang-dev/4FfTBfN2YaI
>
> Is there another area (e.g. an issue on Github) that I should go to 
> further follow this discussion? Did someone come up with a fix?
>

-- 
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] [ANN] primegen.go: Sieve of Atkin prime number generator

[gordonbgood]

Further to the subject of compiler efficiency, the following is the assembler 
code output with array bounds checking turned off (-B) the the inner tight 
composite culling loop of FasterEratspeed above (generated with go tool compile 
-B -S FasterEratspeed.go > FasterEratspeed.asm):

0x0051 00081 (main.go:426)  MOVLR11, CX
0x0054 00084 (main.go:426)  SHRL$5, R11
0x0058 00088 (main.go:428)  MOVL(R9)(R11*4), R13
0x005c 00092 (main.go:430)  MOVL$1, R14
0x0062 00098 (main.go:430)  SHLLCX, R14
0x0065 00101 (main.go:430)  ORL R13, R14
0x0068 00104 (main.go:431)  MOVLR14, (R9)(R11*4)
0x006c 00108 (main.go:429)  LEAL(R12)(CX*1), R11
0x0070 00112 (main.go:425)  CMPLR11, R8
0x0073 00115 (main.go:425)  JCS $0, 81

At 10 instructions, this is about as tight as it gets other than for using the 
more complex read/modify/write version of the ORL instruction, but that doesn't 
seem to save much if any time given instruction latencies.  Note that this code 
has eliminated the "k & 31" for the shift, seeming to recognize that it isn't 
necessary as a long shift can't be greater than 31 anyway, that unlike the 
simple PrimeSpeed program, this properly uses the immediate load of '1', that 
it cleverly uses the LEAL instruction to add the prime value 'q' in R12 to the 
unmodified 'k' value in CX to produce the sum to the original location of 'j' 
in R11 to save another instruction to move the results from CX to R11.

This uses a total of 7 registers being CX, R8, R9, R11, R12, R13, and R14, so 
it would be possible to make it work and run just as fast for x86 code.  This 
includes one register to hold the prime value 'q' in R12, and one register to 
hold the loop limit 'lngthb] in R8.  An array bounds check requires another 
register to hold the array upper bound, which won't be hard for x64 code, but 
will slow x86 code as there won't be enough available registers unless the 
compiler can be made smart enough for certain loop formats to recognize that 
the check isn't necessary, being inherent to the loop check.  Pretty impressive 
if all loops could be compiled as well as this, as this will run at very close 
to C/C++ speed!

When run within L1 cache on a modern Intel CPU without memory or execution 
pipeline(s) bottle-necks, this code will run in about 3.5 CPU cycles per loop 
or about 2.86 instructions per cycle.

I'm looking for the reason that this code is so efficient and the former simple 
PrimeSpeed code was so poor; one clue might be that I used native uint's and 
int's for PrimeSpeed, which are 64-bit on an amd version of the compiler for 
that code so the code was using 'Q' suffix instructions that perhaps it doesn't 
use as efficiently where uint32's and int32's are used here.

Can the compiler guys contribute anything on how to format tight loop code so 
it compiles as well as this?  If the crucial parts of the compiler and 
libraries were written to compile to code as efficient as this, I don't think 
anyone would ahve problems with golang's speed.

-- 
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] [ANN] primegen.go: Sieve of Atkin prime number generator

[gordonbgood]

Further to the subject of compiler efficiency, the following is the assembler 
code output with array bounds checking turned off (-B) the the inner tight 
composite culling loop of FasterEratspeed above (generated with go tool compile 
-B -S FasterEratspeed.go > FasterEratspeed.asm):

0x0051 00081 (main.go:426)  MOVLR11, CX
0x0054 00084 (main.go:426)  SHRL$5, R11
0x0058 00088 (main.go:428)  MOVL(R9)(R11*4), R13
0x005c 00092 (main.go:430)  MOVL$1, R14
0x0062 00098 (main.go:430)  SHLLCX, R14
0x0065 00101 (main.go:430)  ORL R13, R14
0x0068 00104 (main.go:431)  MOVLR14, (R9)(R11*4)
0x006c 00108 (main.go:429)  LEAL(R12)(CX*1), R11
0x0070 00112 (main.go:425)  CMPLR11, R8
0x0073 00115 (main.go:425)  JCS $0, 81

At 10 instructions, this is about as tight as it gets other than for using the 
more complex read/modify/write version of the ORL instruction, but that doesn't 
seem to save much if any time given instruction latencies.  Note that this code 
has eliminated the "k & 31" for the shift, seeming to recognize that it isn't 
necessary as a long shift can't be greater than 31 anyway, that unlike the 
simple PrimeSpeed program, this properly uses the immediate load of '1', that 
it cleverly uses the LEAL instruction to add the prime value 'q' in R12 to the 
unmodified 'k' value in CX to produce the sum to the original location of 'j' 
in R11 to save another instruction to move the results from CX to R11.

This uses a total of 7 registers being CX, R8, R9, R11, R12, R13, and R14, so 
it would be possible to make it work and run just as fast for x86 code.  This 
includes one register to hold the prime value 'q' in R12, and one register to 
hold the loop limit 'lngthb] in R8.  An array bounds check requires another 
register to hold the array upper bound, which won't be hard for x64 code, but 
will slow x86 code as there won't be enough available registers unless the 
compiler can be made smart enough for certain loop formats to recognize that 
the check isn't necessary, being inherent to the loop check.  Pretty impressive 
if all loops could be compiled as well as this, as this will run at very close 
to C/C++ speed!

When run within L1 cache on a modern Intel CPU without memory or execution 
pipeline(s) bottle-necks, this code will run in about 3.5 CPU cycles per loop 
or about 2.86 instructions per cycle.

I'm looking for the reason that this code is so efficient and the former simple 
PrimeSpeed code was so poor; one clue might be that I used native uint's and 
int's for PrimeSpeed, which are 64-bit on an amd version of the compiler for 
that code so the code was using 'Q' suffix instructions that perhaps it doesn't 
use as efficiently where uint32's and int32's are used here.

Can the compiler guys contribute anything on how to format tight loop code so 
it compiles as well as this?  If the crucial parts of the compiler and 
libraries were written to compile to code as efficient as this, I don't think 
anyone would ahve problems with golang's speed.

-- 
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] [ANN] primegen.go: Sieve of Atkin prime number generator

[gordonbgood]

Edit:  Corrected, forgot to change the new count routine to 48 from 8...

We have proven with the straight translation of Daniel Bernstein's C code to 
golang that the Sieve of Eratosthenes (SoE) eratspeed runs about the same speed 
as the Sieve of Atkin (SoA) primespeed for the same range with the same 
optimizations and with John Barham's multi-treading for primespeed disabled 
(set numprocs = 1 in sieve.go), however, golang primespeed is slower with array 
bounds checks enabled due to the complexity of the array operations for the 
prime square free operations.  For both I eliminated the use of the "two" 
shifting look up array table as that caused an extra bounds check, and tuned 
the inner loops in exactly the same way to minimize tight loop time. 

Now that it is already shown that the SoA is inferior for page segmented 
sieving to 1,000,000,000 (one billion), as it only has about 258,000,000 
operations whereas SoE eratspeed has about 405,000,000 operations, meaning that 
the SoA operations are more complex, which is obvious.  However, Bernstein 
crippled eratspeed to only 2/3/5 wheel factorization where it is easily 
possible to use 2/3/5/7 plus pre-culling of the 11/13/17 primes to reduce the 
operations to about 263,000,000 operations, or about 35% less. 

The golang FasterEratspeed that implements this maximum wheel factorization 
version is posted at play.golang at:  https://play.golang.org/p/iKA_s7ocuN and 
runs about 33% faster than the previous standard wheel factorized version, just 
as the ratio of operations suggests that it should; also, because it minimizes 
array access it doesn't matter much whether array bound checking is enabled or 
not.  This is almost as fast as the highly optimized C++ primesieve 
(http://primesieve.org/) run single threaded on my cache access speed 
bottle-necked machine, but on faster machines it will likely be slower than 
primesieve, as much as twice as slow on high end Intel desktop CPU's. 

Actually, this implementation isn't maximally factorized as in some languages 
one is able to also pre-cull by 19 as well, but with golang the overhead of 
creating/handling the extra size of pattern array is about the same as the few 
percent gain. 

So, in this implementation we are coming very close to C/C++ speeds and faster 
than C#/Java; however, I learned much from the exercise and have found that 
very slight changes in the formulation of the tight inner loop(s) can slow the 
speed by at least a factor of two and sometimes up to almost three.  These best 
optimizations aren't always obvious and it is time consuming trying the 
different optimizations to get the fastest code.  Sometimes adding instructions 
actually reduces the execution speed, as the compiler will perhaps change the 
use of registers in a way that there are less stalls or bottle-necks.  For this 
particular implementation and golang version 1.7beta1, it seems that for this 
particular loop, it is optimized quite effectively in spite of having the array 
bounds check and even better without it. 

That should be enough to prove that the SoA is just an interesting intellectual 
exercise, as for page seqmented sieves as these it has more complexity and is 
thus slower than the maximally factorized SoE, and also does not support its 
theoretical O(n) asymptotic complexity as with increasing range there is an 
ever increasing cost in code overhead, whereas the SoE comes very close to 
maintaining its theoretical O(n log log n) performance.

To @Michael Jones:  The error was that it was calculating the primes to over a 
billion but only counting one sixth of them, the culling time (which is almost 
all of the time) is the same.  It wouldn't take any longer to show the last 
prime.  So this program is almost six times faster than yours, as it likely 
should be in that it uses the extreme factorization to reduce the operations by 
about a factor of four from a simple odds only SoE.

Yes, it is a little complicated doing the maximum wheel factorization, but not 
that much more complicated than the original C eratspeed; much of the extra 
code comes from implementing the pre-culling pattern and copying it into the 
page segment buffers, but about half the speed gain comes from that so it was 
worth it.  This is a different algorithm than many SoE implementations, as 
rather than putting all wheel residuals in the same word or adjacent words, it 
uses separate bit-packed arrays for each residual, with one bit across all of 
the 48 residual array representing a range of 210.  Thus, instead of a 
increased bit packing of a factor of two for odds-only sieves, there is a bit 
packing factor of 48 to 210 or a factor of over four.  And it is to processing 
each residual separately that it owes its speed.  It may look complicated, but 
less complicated than the extreme loop unrolling that Kim Waisch had to resort 
to in order to get the performance of primesieve.

That said, this code was originally written to demo

Re: [go-nuts] [ANN] primegen.go: Sieve of Atkin prime number generator

[Michael Jones]

Your code (with slightly changed print formatting) on my MacBook Pro:

$ go install
$ time fasterEratspeed 
  Init:   2.885352ms
Search: 284.849689ms, found 8621475 primes up to 1018429650
 Total: 287.735041ms

real0m0.302s
user0m0.287s
sys 0m0.007s

It is pretty complicated to me so I don’t understand why the values printed are 
as they are. My sense of prime number counts is that the 8621475th prime is 
153339973. (Mathematica thinks so too.) 

My old illustrative Go SoE code does this calculation pretty quickly:

BenchmarkNew153339973  5 312174802 ns/op

That’s 312.174802ms to construct and retain a sieve for the first 153339973 
integers, count the total number of primes included, and determine the final 
one in the range. Compiling with “-B” is a big help here...

BenchmarkNew153339973  5 281989575 ns/op

...reducing the total time to 281.989575ms

> On Jun 20, 2016, at 3:40 AM, gordonbg...@gmail.com wrote:
> 
> We have proven with the straight translation of Daniel Bernstein's C code to 
> golang that the Sieve of Eratosthenes (SoE) eratspeed rans about the same 
> speed as the Sieve of Atkin (SoA) primespeed for the same range with the same 
> optimizations and with John Barham's multi-treading for primespeed disabled 
> (set numprocs = 1 in sieve.go), however golang primespeed is slower with 
> array bounds checks enabled due to the complexity of the array operations for 
> the prime square free operations.  For both I eliminated the use of the "two" 
> shifting look up array table as that caused an extra bounds check, and tuned 
> the inner loops in exactly the same way to minimize tight loop time.
> 
> Now that already shows that the SoA is inferior for page segmented sieving to 
> 1,000,000,000 (one billion), as it only has about 258,000,000 operations 
> whereas SoE eratspeed has about 405,000,000 operations, meaning that the SoA 
> operations are more complex, which is obvious.  However, Bernstein crippled 
> eratspeed to only 2/3/5 wheel factorization where it is easily possible to 
> use 2/3/5/7 plus pre-culling of the 11/13/17 primes to reduce the operations 
> to about 263,000,000 operations, or about 35% less.
> 
> The golang FasterEratspeed that implements this maximum wheel factorization 
> version is posted at play.golang at:  https://play.golang.org/p/8Bo04bnT5F 
> and runs about 33% faster than the previous standard wheel factorized 
> version, just as the ratio of operations suggests that it should; also, 
> because it minimizes array access it doesn't matter much whether array bound 
> checking is enabled or not.  This is almost as fast as the highly optimized 
> C++ primesieve (http://primesieve.org/) run signle threaded on my cache 
> access speed bottle-necked machine, but on faster machines it will be slower 
> than primesieve, as much as twice as slow on high end Intel desktop CPU's.
> 
> Actually, this implementation isn't maximally factorized as in some languages 
> one is able to also pre-cull by 19 as well, but with golang the overhead of 
> creating handling the extra size of pattern array is about the same as the 
> few percent gain.
> 
> So, in this implementation we are coming very close to C/C++ speeds and 
> faster than C#/Java; however, I learned much from the exercise and have found 
> that very slight changes in the formulation of the tight inner loop(s) can 
> slow the speed by at least a factor of two and sometimes up to almost three.  
> These best opimizations aren't always obvious and it is time consuming trying 
> the different optimizations to get the fastest code.  Sometimes adding 
> instructions actually reduces the execution speed, as the compiler will 
> perhaps change the use of registers in a way that there are less stalls or 
> bottle-necks.  For this particular implementation and golang version 
> 1.7beta1, it seems that for this particular loop, it is optimized quite 
> effectively in spite of having the array bounds check and even better without 
> it.
> 
> That should be enough to prove that the SoA is just an interesting 
> intellectual exercise, as for page seqmented sieves as these it has more 
> complexity and is thus slower than the maximally factorized SoE, and also 
> does not support its theoretical O(n) asymptotic complexity as with 
> increasing range there is an ever increasing cost in code overhead, whereas 
> the SoE comes very close to maintaining its theoretical O(n log log n) 
> performance.
> 
> -- 
> 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 go

Re: [go-nuts] Re: [ANN] primegen.go: Sieve of Atkin prime number generator

[gordonbgood]

We have proven with the straight translation of Daniel Bernstein's C code to 
golang that the Sieve of Eratosthenes (SoE) eratspeed rans about the same speed 
as the Sieve of Atkin (SoA) primespeed for the same range with the same 
optimizations and with John Barham's multi-treading for primespeed disabled 
(set numprocs = 1 in sieve.go), however golang primespeed is slower with array 
bounds checks enabled due to the complexity of the array operations for the 
prime square free operations.  For both I eliminated the use of the "two" 
shifting look up array table as that caused an extra bounds check, and tuned 
the inner loops in exactly the same way to minimize tight loop time.

Now that already shows that the SoA is inferior for page segmented sieving to 
1,000,000,000 (one billion), as it only has about 258,000,000 operations 
whereas SoE eratspeed has about 405,000,000 operations, meaning that the SoA 
operations are more complex, which is obvious.  However, Bernstein crippled 
eratspeed to only 2/3/5 wheel factorization where it is easily possible to use 
2/3/5/7 plus pre-culling of the 11/13/17 primes to reduce the operations to 
about 263,000,000 operations, or about 35% less.

The golang FasterEratspeed that implements this maximum wheel factorization 
version is posted at play.golang at:  https://play.golang.org/p/8Bo04bnT5F and 
runs about 33% faster than the previous standard wheel factorized version, just 
as the ratio of operations suggests that it should; also, because it minimizes 
array access it doesn't matter much whether array bound checking is enabled or 
not.  This is almost as fast as the highly optimized C++ primesieve 
(http://primesieve.org/) run signle threaded on my cache access speed 
bottle-necked machine, but on faster machines it will be slower than 
primesieve, as much as twice as slow on high end Intel desktop CPU's.

Actually, this implementation isn't maximally factorized as in some languages 
one is able to also pre-cull by 19 as well, but with golang the overhead of 
creating handling the extra size of pattern array is about the same as the few 
percent gain.

So, in this implementation we are coming very close to C/C++ speeds and faster 
than C#/Java; however, I learned much from the exercise and have found that 
very slight changes in the formulation of the tight inner loop(s) can slow the 
speed by at least a factor of two and sometimes up to almost three.  These best 
opimizations aren't always obvious and it is time consuming trying the 
different optimizations to get the fastest code.  Sometimes adding instructions 
actually reduces the execution speed, as the compiler will perhaps change the 
use of registers in a way that there are less stalls or bottle-necks.  For this 
particular implementation and golang version 1.7beta1, it seems that for this 
particular loop, it is optimized quite effectively in spite of having the array 
bounds check and even better without it.

That should be enough to prove that the SoA is just an interesting intellectual 
exercise, as for page seqmented sieves as these it has more complexity and is 
thus slower than the maximally factorized SoE, and also does not support its 
theoretical O(n) asymptotic complexity as with increasing range there is an 
ever increasing cost in code overhead, whereas the SoE comes very close to 
maintaining its theoretical O(n log log n) performance.

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