[jira] [Created] (THRIFT-4255) Go generator has type errors when in read/write functions for set

2017-07-17 Thread Davin Chia (JIRA)
Davin Chia created THRIFT-4255:
--

 Summary: Go generator has type errors when in read/write functions 
for set
 Key: THRIFT-4255
 URL: https://issues.apache.org/jira/browse/THRIFT-4255
 Project: Thrift
  Issue Type: Bug
  Components: Go - Compiler
Affects Versions: 0.10.0
Reporter: Davin Chia


Given the following thrift definition:

{code:java} struct CustomSet {
  1: required set values;
}{code}

The following go code is generated:
{code:java}
type CustomSet struct {
  Values map[string]struct{} `thrift:"values,1,required" db:"values" 
json:"values"`
}

func (p *ByteArraySet)  ReadField1(iprot thrift.TProtocol) error {
  _, size, err := iprot.ReadSetBegin()
  if err != nil {
return thrift.PrependError("error reading set begin: ", err)
  }
  tSet := make(map[string]struct{}, size)
  p.Values =  tSet
  for i := 0; i < size; i ++ {
var _elem2 []byte
if v, err := iprot.ReadBinary(); err != nil {
return thrift.PrependError("error reading field 0: ", err)
} else {
_elem2 = v
}
p.Values[_elem2] = struct{}{}
  }
  if err := iprot.ReadSetEnd(); err != nil {
return thrift.PrependError("error reading set end: ", err)
  }
  return nil
}

func (p *ByteArraySet) writeField1(oprot thrift.TProtocol) (err error) {
  if err := oprot.WriteFieldBegin("values", thrift.SET, 1); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write field begin error 
1:values: ", p), err) }
  if err := oprot.WriteSetBegin(thrift.STRING, len(p.Values)); err != nil {
return thrift.PrependError("error writing set begin: ", err)
  }
  for v, _ := range p.Values {
if err := oprot.WriteBinary(v); err != nil {
return thrift.PrependError(fmt.Sprintf("%T. (0) field write error: ", p), 
err) }
  }
  if err := oprot.WriteSetEnd(); err != nil {
return thrift.PrependError("error writing set end: ", err)
  }
  if err := oprot.WriteFieldEnd(); err != nil {
return thrift.PrependError(fmt.Sprintf("%T write field end error 1:values: 
", p), err) }
  return err
}
{code}

In the *Read* function, *elem_2* needs to be cast to *string* before its used 
as a key to *Values*.
In the *Write* function, *v* needs to be case to *byte[]* before its passed to 
*WriteBinary*.

I have opened a couple of issues today and will slowly work through them as 
time frees up.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Comment Edited] (THRIFT-4253) Go generator assigns strings to field in const instead of pointers.

2017-07-17 Thread Davin Chia (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090895#comment-16090895
 ] 

Davin Chia edited comment on THRIFT-4253 at 7/18/17 3:44 AM:
-

Thanks for the quick reply [~jensg]. This is the first time I am contributing 
to a large C++ open source project, or writing much C++ to be honest, and it 
will be good to get some guidance on development workflow. I'm assuming I clone 
https://github.com/apache/thrift, make a branch and start working. Happy to 
jump on some other communication medium if that is better for you.

If you can spare a few minutes, it will also be nice to have a point in the 
code I can start from. Thanks.


was (Author: davinc):
Thanks for the quick reply [~jensg]. This is the first time I am contributing 
to a large C++ open source project, or writing much C++ to be honest, and it 
will be good to get some guidance on development workflow. I'm assuming I clone 
https://github.com/apache/thrift, make a branch and start working. Happy to 
jump on some other communication medium if that is better for you.

If you spare a few minutes, it will also be nice to have a point in the code I 
can start from. Thanks.

> Go generator assigns strings to field in const instead of pointers.
> ---
>
> Key: THRIFT-4253
> URL: https://issues.apache.org/jira/browse/THRIFT-4253
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.10.0
> Environment: Generated using docker-thrift.
>Reporter: Davin Chia
>
> Given the follow thrift definition:
> {code:java}
> struct custom {
>   1: required string field_a;
>   2: optional string field_b;
> }
> {code}
> with the following constant map defined in the same file:
> {code:java}
> const map custom_map = {
>   ...,
>   42 : { 'field_a':'www.testa.com', 'field_b':'www.testb.com'},
>   ...,
> }
> {code}
> Thrift generates the following go struct in the main {code:java}x.go{code} 
> file:
> {code:java}
> type Custom struct {
>   FieldA string `thrift:"field_a,required" db:"field_a" json:"field_a"`
>   FieldB *string `thrift:"field_b,2" db:"field_b" json:"field_b,omitempty"`
> }
> {code}
> with the corresponding assignments in the {code:java} X-consts.go {code} file:
> {code:java}
> CUSTOM_MAP = map[int]*Custom {
>   ...,
>   42:  {FieldA: "www.testa.com", FieldB: "www.testb.com"},
>   ...,
> }
> {code}
> I assume field_b's pointer type is to allow for null values as per the 
> optional. The generator should be assigning pointers instead of strings. 
> I'm not sure how much effort it would take to fix this. I am encountering 
> this problem at work right and would be very happy to starting working on 
> this with some guidance from experts around here. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Comment Edited] (THRIFT-4253) Go generator assigns strings to field in const instead of pointers.

2017-07-17 Thread Davin Chia (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090895#comment-16090895
 ] 

Davin Chia edited comment on THRIFT-4253 at 7/18/17 3:15 AM:
-

Thanks for the quick reply [~jensg]. This is the first time I am contributing 
to a large C++ open source project, or writing much C++ to be honest, and it 
will be good to get some guidance on development workflow. I'm assuming I clone 
https://github.com/apache/thrift, make a branch and start working. Happy to 
jump on some other communication medium if that is better for you.

If you spare a few minutes, it will also be nice to have a point in the code I 
can start from. Thanks.


was (Author: davinc):
Thanks for the quick reply [~jensg]. This is the first time I am contributing 
to a large C++ open source project, or writing much C++ to be honest, and it 
will be good to get some guidance on development workflow. I'm assuming I clone 
https://github.com/apache/thrift, make a branch and start working.

If you spare a few minutes, it will also be nice to have a point in the code I 
can start from. Thanks.

> Go generator assigns strings to field in const instead of pointers.
> ---
>
> Key: THRIFT-4253
> URL: https://issues.apache.org/jira/browse/THRIFT-4253
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.10.0
> Environment: Generated using docker-thrift.
>Reporter: Davin Chia
>
> Given the follow thrift definition:
> {code:java}
> struct custom {
>   1: required string field_a;
>   2: optional string field_b;
> }
> {code}
> with the following constant map defined in the same file:
> {code:java}
> const map custom_map = {
>   ...,
>   42 : { 'field_a':'www.testa.com', 'field_b':'www.testb.com'},
>   ...,
> }
> {code}
> Thrift generates the following go struct in the main {code:java}x.go{code} 
> file:
> {code:java}
> type Custom struct {
>   FieldA string `thrift:"field_a,required" db:"field_a" json:"field_a"`
>   FieldB *string `thrift:"field_b,2" db:"field_b" json:"field_b,omitempty"`
> }
> {code}
> with the corresponding assignments in the {code:java} X-consts.go {code} file:
> {code:java}
> CUSTOM_MAP = map[int]*Custom {
>   ...,
>   42:  {FieldA: "www.testa.com", FieldB: "www.testb.com"},
>   ...,
> }
> {code}
> I assume field_b's pointer type is to allow for null values as per the 
> optional. The generator should be assigning pointers instead of strings. 
> I'm not sure how much effort it would take to fix this. I am encountering 
> this problem at work right and would be very happy to starting working on 
> this with some guidance from experts around here. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Comment Edited] (THRIFT-4253) Go generator assigns strings to field in const instead of pointers.

2017-07-17 Thread Davin Chia (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090895#comment-16090895
 ] 

Davin Chia edited comment on THRIFT-4253 at 7/18/17 3:13 AM:
-

Thanks for the quick reply [~jensg]. This is the first time I am contributing 
to a large C++ open source project, or writing much C++ to be honest, and it 
will be good to get some guidance on development workflow. I'm assuming I clone 
https://github.com/apache/thrift, make a branch and start working.

If you spare a few minutes, it will also be nice to have a point in the code I 
can start from. Thanks.


was (Author: davinc):
Thanks for the quick reply [~jensg]. This is the first time I am contributing 
to a large C++ open source project, or writing much C++ to be honest, and it 
will be good to get some guidance on development workflow.  

Immediate questions are (Again sorry if they sound newbie, because I am): Where 
can I check the code out? What is the typical build for C++ projects? I also 
have a question about testing, but I now know where to do that 
(ConstantsDemo.thrift).

If you spare a few minutes, it will also be nice to have a point in the code I 
can start from. Thanks.

> Go generator assigns strings to field in const instead of pointers.
> ---
>
> Key: THRIFT-4253
> URL: https://issues.apache.org/jira/browse/THRIFT-4253
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.10.0
> Environment: Generated using docker-thrift.
>Reporter: Davin Chia
>
> Given the follow thrift definition:
> {code:java}
> struct custom {
>   1: required string field_a;
>   2: optional string field_b;
> }
> {code}
> with the following constant map defined in the same file:
> {code:java}
> const map custom_map = {
>   ...,
>   42 : { 'field_a':'www.testa.com', 'field_b':'www.testb.com'},
>   ...,
> }
> {code}
> Thrift generates the following go struct in the main {code:java}x.go{code} 
> file:
> {code:java}
> type Custom struct {
>   FieldA string `thrift:"field_a,required" db:"field_a" json:"field_a"`
>   FieldB *string `thrift:"field_b,2" db:"field_b" json:"field_b,omitempty"`
> }
> {code}
> with the corresponding assignments in the {code:java} X-consts.go {code} file:
> {code:java}
> CUSTOM_MAP = map[int]*Custom {
>   ...,
>   42:  {FieldA: "www.testa.com", FieldB: "www.testb.com"},
>   ...,
> }
> {code}
> I assume field_b's pointer type is to allow for null values as per the 
> optional. The generator should be assigning pointers instead of strings. 
> I'm not sure how much effort it would take to fix this. I am encountering 
> this problem at work right and would be very happy to starting working on 
> this with some guidance from experts around here. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (THRIFT-4254) Go generator does not respect typedef types when generating read/write functions.

2017-07-17 Thread Davin Chia (JIRA)
Davin Chia created THRIFT-4254:
--

 Summary: Go generator does not respect typedef types when 
generating read/write functions.
 Key: THRIFT-4254
 URL: https://issues.apache.org/jira/browse/THRIFT-4254
 Project: Thrift
  Issue Type: Bug
  Components: Go - Compiler
Affects Versions: 0.10.0
Reporter: Davin Chia


Give the following thrift definitions:
 
{code:java}
typedef i64   RequestId 

struct Custom {
  optional set field_a;
}
{code}

The following go code is generated:

{code:java}
type RequestId int64

type Custom struct {
  FieldA map[RequestId]struct{}
}

...

func (p *Custom)  ReadField1(iprot thrift.TProtocol) error {
  _, size, err := iprot.ReadSetBegin()
  if err != nil {
return thrift.PrependError("error reading set begin: ", err)
  }
  tSet := make(map[int64]struct{}, size)
  p.ActiveImportIds =  tSet
  for i := 0; i < size; i ++ {
var _elem1 int64
if v, err := iprot.ReadI64(); err != nil {
return thrift.PrependError("error reading field 0: ", err)
} else {
_elem1 = v
}
p.FieldA[_elem1] = struct{}{}
  }
  if err := iprot.ReadSetEnd(); err != nil {
return thrift.PrependError("error reading set end: ", err)
  }
  return nil
}
{code}

There are two errors here:
1. {code:java}tSet{code} should be {code:java} map[RequestId]struct{} {code} 
and not {code:java}map[int64]struct{}{code}.
2. {code:java} elem_1 {code}should be of type {code:java}RequestId{code} and 
the values need to be case to {code:java}RequestId{code} before assigning to 
{code:java}elem_1{code}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (THRIFT-4253) Go generator assigns strings to field in const instead of pointers.

2017-07-17 Thread Davin Chia (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090895#comment-16090895
 ] 

Davin Chia commented on THRIFT-4253:


Thanks for the quick reply [~jensg]. This is the first time I am contributing 
to a large C++ open source project, or writing much C++ to be honest, and it 
will be good to get some guidance on development workflow.  

Immediate questions are (Again sorry if they sound newbie, because I am): Where 
can I check the code out? What is the typical build for C++ projects? I also 
have a question about testing, but I now know where to do that 
(ConstantsDemo.thrift).

If you spare a few minutes, it will also be nice to have a point in the code I 
can start from. Thanks.

> Go generator assigns strings to field in const instead of pointers.
> ---
>
> Key: THRIFT-4253
> URL: https://issues.apache.org/jira/browse/THRIFT-4253
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.10.0
> Environment: Generated using docker-thrift.
>Reporter: Davin Chia
>
> Given the follow thrift definition:
> {code:java}
> struct custom {
>   1: required string field_a;
>   2: optional string field_b;
> }
> {code}
> with the following constant map defined in the same file:
> {code:java}
> const map custom_map = {
>   ...,
>   42 : { 'field_a':'www.testa.com', 'field_b':'www.testb.com'},
>   ...,
> }
> {code}
> Thrift generates the following go struct in the main {code:java}x.go{code} 
> file:
> {code:java}
> type Custom struct {
>   FieldA string `thrift:"field_a,required" db:"field_a" json:"field_a"`
>   FieldB *string `thrift:"field_b,2" db:"field_b" json:"field_b,omitempty"`
> }
> {code}
> with the corresponding assignments in the {code:java} X-consts.go {code} file:
> {code:java}
> CUSTOM_MAP = map[int]*Custom {
>   ...,
>   42:  {FieldA: "www.testa.com", FieldB: "www.testb.com"},
>   ...,
> }
> {code}
> I assume field_b's pointer type is to allow for null values as per the 
> optional. The generator should be assigning pointers instead of strings. 
> I'm not sure how much effort it would take to fix this. I am encountering 
> this problem at work right and would be very happy to starting working on 
> this with some guidance from experts around here. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (THRIFT-2063) Go compiler cannot create code for maps with complex/binary keys

2017-07-17 Thread Davin Chia (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090880#comment-16090880
 ] 

Davin Chia commented on THRIFT-2063:


Ah sorry for the noise. I am definitely going to fix this. My intention on 
opening discussion was to arrive at a community accepted solution. This is 
because I am not a Go expert and so am not sure about the best solution. The 
current monkey patch I am using is to convert all complex keys into strings, 
which is definitely only temporary. I will get to this after tackling 
*https://issues.apache.org/jira/browse/THRIFT-4253*.

> Go compiler cannot create code for maps with complex/binary keys
> 
>
> Key: THRIFT-2063
> URL: https://issues.apache.org/jira/browse/THRIFT-2063
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Reporter: Remo Hertig
>
> trying to generate code for ThriftTest leads to:
> {code}
> ../../compiler/cpp/thrift --gen go ../ThriftTest.thrift 
> [WARNING:/tbHD/Home/nairboon/dev/thrift/test/ThriftTest.thrift:41] No 
> generator named 'noexist' could be found!
> [WARNING:/tbHD/Home/nairboon/dev/thrift/test/ThriftTest.thrift:42] cpp 
> generator does not accept 'noexist' as sub-namespace!
> Error: Cannot produce a valid type for a Go map key: map[int32]bool - 
> aborting.{code}
> the affected struct seems to be #3: 
> {code}
> struct CrazyNesting {
>   1: string string_field,
>   2: optional set set_field,
>   3: required list< map> 
> list_field,
>   4: binary binary_field
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Comment Edited] (THRIFT-4253) Go generator assigns strings to field in const instead of pointers.

2017-07-17 Thread Jens Geyer (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090591#comment-16090591
 ] 

Jens Geyer edited comment on THRIFT-4253 at 7/17/17 9:25 PM:
-

Confirmed, trying this ends up in a "{{cannot use "test" (type string) as type 
*string in field value}}". 

That seems absolutely wrong, and besides fixing it we also should integrate an 
test into 
[ConstantsDemo.thrift|https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=test/ConstantsDemo.thrift;hb=HEAD]

[~DavinC], what specific questions that I can answer do you have?


was (Author: jensg):
Confirmed, trying this ends up in a "{{cannot use "test" (type string) as type 
*string in field value}}". 

That seems absolutely wrong, and besides fixing it we also should integrate an 
test into 
[ConstantsDemo.thrift|https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=test/ConstantsDemo.thrift;hb=HEAD]

> Go generator assigns strings to field in const instead of pointers.
> ---
>
> Key: THRIFT-4253
> URL: https://issues.apache.org/jira/browse/THRIFT-4253
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.10.0
> Environment: Generated using docker-thrift.
>Reporter: Davin Chia
>
> Given the follow thrift definition:
> {code:java}
> struct custom {
>   1: required string field_a;
>   2: optional string field_b;
> }
> {code}
> with the following constant map defined in the same file:
> {code:java}
> const map custom_map = {
>   ...,
>   42 : { 'field_a':'www.testa.com', 'field_b':'www.testb.com'},
>   ...,
> }
> {code}
> Thrift generates the following go struct in the main {code:java}x.go{code} 
> file:
> {code:java}
> type Custom struct {
>   FieldA string `thrift:"field_a,required" db:"field_a" json:"field_a"`
>   FieldB *string `thrift:"field_b,2" db:"field_b" json:"field_b,omitempty"`
> }
> {code}
> with the corresponding assignments in the {code:java} X-consts.go {code} file:
> {code:java}
> CUSTOM_MAP = map[int]*Custom {
>   ...,
>   42:  {FieldA: "www.testa.com", FieldB: "www.testb.com"},
>   ...,
> }
> {code}
> I assume field_b's pointer type is to allow for null values as per the 
> optional. The generator should be assigning pointers instead of strings. 
> I'm not sure how much effort it would take to fix this. I am encountering 
> this problem at work right and would be very happy to starting working on 
> this with some guidance from experts around here. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (THRIFT-4253) Go generator assigns strings to field in const instead of pointers.

2017-07-17 Thread Jens Geyer (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090591#comment-16090591
 ] 

Jens Geyer commented on THRIFT-4253:


Confirmed, trying this ends up in a "{{cannot use "test" (type string) as type 
*string in field value}}". 

That seems absolutely wrong, and besides fixing it we also should integrate an 
test into 
[ConstantsDemo.thrift|https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=test/ConstantsDemo.thrift;hb=HEAD]

> Go generator assigns strings to field in const instead of pointers.
> ---
>
> Key: THRIFT-4253
> URL: https://issues.apache.org/jira/browse/THRIFT-4253
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.10.0
> Environment: Generated using docker-thrift.
>Reporter: Davin Chia
>
> Given the follow thrift definition:
> {code:java}
> struct custom {
>   1: required string field_a;
>   2: optional string field_b;
> }
> {code}
> with the following constant map defined in the same file:
> {code:java}
> const map custom_map = {
>   ...,
>   42 : { 'field_a':'www.testa.com', 'field_b':'www.testb.com'},
>   ...,
> }
> {code}
> Thrift generates the following go struct in the main {code:java}x.go{code} 
> file:
> {code:java}
> type Custom struct {
>   FieldA string `thrift:"field_a,required" db:"field_a" json:"field_a"`
>   FieldB *string `thrift:"field_b,2" db:"field_b" json:"field_b,omitempty"`
> }
> {code}
> with the corresponding assignments in the {code:java} X-consts.go {code} file:
> {code:java}
> CUSTOM_MAP = map[int]*Custom {
>   ...,
>   42:  {FieldA: "www.testa.com", FieldB: "www.testb.com"},
>   ...,
> }
> {code}
> I assume field_b's pointer type is to allow for null values as per the 
> optional. The generator should be assigning pointers instead of strings. 
> I'm not sure how much effort it would take to fix this. I am encountering 
> this problem at work right and would be very happy to starting working on 
> this with some guidance from experts around here. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (THRIFT-2063) Go compiler cannot create code for maps with complex/binary keys

2017-07-17 Thread Jens Geyer (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090566#comment-16090566
 ] 

Jens Geyer commented on THRIFT-2063:


You can bump this in 5-Minutes intervals, but that will only fill the mailing 
list and disappoint people. 
This is Open Source, which by definition lives by *contributions, not decibels*.

> Go compiler cannot create code for maps with complex/binary keys
> 
>
> Key: THRIFT-2063
> URL: https://issues.apache.org/jira/browse/THRIFT-2063
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Reporter: Remo Hertig
>
> trying to generate code for ThriftTest leads to:
> {code}
> ../../compiler/cpp/thrift --gen go ../ThriftTest.thrift 
> [WARNING:/tbHD/Home/nairboon/dev/thrift/test/ThriftTest.thrift:41] No 
> generator named 'noexist' could be found!
> [WARNING:/tbHD/Home/nairboon/dev/thrift/test/ThriftTest.thrift:42] cpp 
> generator does not accept 'noexist' as sub-namespace!
> Error: Cannot produce a valid type for a Go map key: map[int32]bool - 
> aborting.{code}
> the affected struct seems to be #3: 
> {code}
> struct CrazyNesting {
>   1: string string_field,
>   2: optional set set_field,
>   3: required list< map> 
> list_field,
>   4: binary binary_field
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Comment Edited] (THRIFT-2063) Go compiler cannot create code for maps with complex/binary keys

2017-07-17 Thread Davin Chia (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16087783#comment-16087783
 ] 

Davin Chia edited comment on THRIFT-2063 at 7/17/17 8:57 PM:
-

Bumping this. I know this is an old issue, but I am currently running into this 
problem while introducing go into our code base. I am compiling using thrift 
0.10.0. Is there an update on this? Has there been a consensus to write thrift 
definitions without complex keys to avoid this problem and are there current 
work arounds? Or Is this still an open issue with solutions open to discussion? 
 [~apesternikov] [~jensg] [~traviscline]


was (Author: davinc):
Bumping this. I know this is an old issue, but I am currently running into this 
problem while introducing go into our code base. I am compiling using thrift 
0.10.0. Is there an update on this? Has there been a consensus to write thrift 
definitions without complex keys to avoid this problem and are there current 
work arounds? Or Is this still an open issue with solutions open to discussion? 
 [~apesternikov]

> Go compiler cannot create code for maps with complex/binary keys
> 
>
> Key: THRIFT-2063
> URL: https://issues.apache.org/jira/browse/THRIFT-2063
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Reporter: Remo Hertig
>
> trying to generate code for ThriftTest leads to:
> {code}
> ../../compiler/cpp/thrift --gen go ../ThriftTest.thrift 
> [WARNING:/tbHD/Home/nairboon/dev/thrift/test/ThriftTest.thrift:41] No 
> generator named 'noexist' could be found!
> [WARNING:/tbHD/Home/nairboon/dev/thrift/test/ThriftTest.thrift:42] cpp 
> generator does not accept 'noexist' as sub-namespace!
> Error: Cannot produce a valid type for a Go map key: map[int32]bool - 
> aborting.{code}
> the affected struct seems to be #3: 
> {code}
> struct CrazyNesting {
>   1: string string_field,
>   2: optional set set_field,
>   3: required list< map> 
> list_field,
>   4: binary binary_field
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (THRIFT-4253) Go generator assigns strings to field in const instead of pointers.

2017-07-17 Thread Davin Chia (JIRA)
Davin Chia created THRIFT-4253:
--

 Summary: Go generator assigns strings to field in const instead of 
pointers.
 Key: THRIFT-4253
 URL: https://issues.apache.org/jira/browse/THRIFT-4253
 Project: Thrift
  Issue Type: Bug
  Components: Go - Compiler
Affects Versions: 0.10.0
 Environment: Generated using docker-thrift.
Reporter: Davin Chia


Given the follow thrift definition:
{code:java}
struct custom {
  1: required string field_a;
  2: optional string field_b;
}
{code}

with the following constant map defined in the same file:

{code:java}
const map custom_map = {
  ...,
  42 : { 'field_a':'www.testa.com', 'field_b':'www.testb.com'},
  ...,
}
{code}

Thrift generates the following go struct in the main {code:java}x.go{code} file:
{code:java}
type Custom struct {
  FieldA string `thrift:"field_a,required" db:"field_a" json:"field_a"`
  FieldB *string `thrift:"field_b,2" db:"field_b" json:"field_b,omitempty"`
}
{code}
with the corresponding assignments in the {code:java} X-consts.go {code} file:

{code:java}
CUSTOM_MAP = map[int]*Custom {
  ...,
  42:  {FieldA: "www.testa.com", FieldB: "www.testb.com"},
  ...,
}
{code}

I assume field_b's pointer type is to allow for null values as per the 
optional. The generator should be assigning pointers instead of strings. 

I'm not sure how much effort it would take to fix this. I am encountering this 
problem at work right and would be very happy to starting working on this with 
some guidance from experts around here. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Comment Edited] (THRIFT-2063) Go compiler cannot create code for maps with complex/binary keys

2017-07-17 Thread Davin Chia (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16087783#comment-16087783
 ] 

Davin Chia edited comment on THRIFT-2063 at 7/17/17 8:00 PM:
-

Bumping this. I know this is an old issue, but I am currently running into this 
problem while introducing go into our code base. I am compiling using thrift 
0.10.0. Is there an update on this? Has there been a consensus to write thrift 
definitions without complex keys to avoid this problem and are there current 
work arounds? Or Is this still an open issue with solutions open to discussion? 
 [~apesternikov]


was (Author: davinc):
Bumping this. I know this is an old issue, but I am currently running into this 
problem while introducing go into our code base. I am compiling using thrift 
0.10.0. Is there an update on this? Has there been a consensus to write thrift 
definitions without complex keys to avoid this problem and are there current 
work arounds? Or Is this still an open issue with solutions open to discussion? 
 

> Go compiler cannot create code for maps with complex/binary keys
> 
>
> Key: THRIFT-2063
> URL: https://issues.apache.org/jira/browse/THRIFT-2063
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Reporter: Remo Hertig
>
> trying to generate code for ThriftTest leads to:
> {code}
> ../../compiler/cpp/thrift --gen go ../ThriftTest.thrift 
> [WARNING:/tbHD/Home/nairboon/dev/thrift/test/ThriftTest.thrift:41] No 
> generator named 'noexist' could be found!
> [WARNING:/tbHD/Home/nairboon/dev/thrift/test/ThriftTest.thrift:42] cpp 
> generator does not accept 'noexist' as sub-namespace!
> Error: Cannot produce a valid type for a Go map key: map[int32]bool - 
> aborting.{code}
> the affected struct seems to be #3: 
> {code}
> struct CrazyNesting {
>   1: string string_field,
>   2: optional set set_field,
>   3: required list< map> 
> list_field,
>   4: binary binary_field
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[GitHub] thrift pull request #1309: Use build tags to support context.

2017-07-17 Thread dcelasun
Github user dcelasun commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1309#discussion_r127776518
  
--- Diff: lib/go/thrift/multiplexed_processor.go ---
@@ -1,3 +1,5 @@
+// +build go1.7
--- End diff --

Maybe this file should be named `multiplexed_protocol_go17.go` or something 
like that to be consistent with `TMultiplexedProcessor` in 
`multiplexed_protocol.go`? 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] thrift pull request #1309: Use build tags to support context.

2017-07-17 Thread dcelasun
Github user dcelasun commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1309#discussion_r127775849
  
--- Diff: lib/go/thrift/simple_server2.go ---
@@ -1,180 +0,0 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements. See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership. The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License. You may obtain a copy of the License at
- *
- *   http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing,
- * software distributed under the License is distributed on an
- * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- * KIND, either express or implied. See the License for the
- * specific language governing permissions and limitations
- * under the License.
- */
-
-package thrift
-
-import (
-   "context"
-   "log"
-   "runtime/debug"
-   "sync"
-)
-
-/*
- * This is only a simple sample same as TSimpleServer but add context
- * usage support.
- */
-type TSimpleServer2 struct {
--- End diff --

Why was this removed?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] thrift pull request #1309: Use build tags to support context.

2017-07-17 Thread dcelasun
Github user dcelasun commented on a diff in the pull request:

https://github.com/apache/thrift/pull/1309#discussion_r127774140
  
--- Diff: compiler/cpp/src/thrift/generate/t_go_generator.cc ---
@@ -3746,4 +3746,4 @@ THRIFT_REGISTER_GENERATOR(go, "Go",
   "read_write_private\n"
   " Make read/write methods 
private, default is public Read/Write\n" \
   "use_context\n"
-  " Make service method 
receive a context as first argument.\n")
+  " Make service method 
receive a context as first argument, only go1.7+ is supported.\n")
--- End diff --

Can we support `x/net/context` for go<1.7?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (THRIFT-4236) Support context in go generated code.

2017-07-17 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-4236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090063#comment-16090063
 ] 

ASF GitHub Bot commented on THRIFT-4236:


GitHub user taozle opened a pull request:

https://github.com/apache/thrift/pull/1309

Use build tags to support context.

As the comment in https://issues.apache.org/jira/browse/THRIFT-4236, this 
PR use build tags to support context in go1.7 above.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/taozle/thrift context

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1309.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1309


commit 0df5965eb2a35793f19de1b2696e3c4afb6b5132
Author: taozle 
Date:   2017-07-17T16:40:42Z

Use build tags to support context.




> Support context in go generated code.
> -
>
> Key: THRIFT-4236
> URL: https://issues.apache.org/jira/browse/THRIFT-4236
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Compiler, Go - Library
>Reporter: taozle
>Assignee: taozle
> Fix For: 0.11.0
>
>
> Since context is widely used in go's community, and there is lots of 
> advantage to use context such as control timeout, carry extra info in one 
> request etc, so is there any plan for this? i just searched the issues but 
> didn't find anything about this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[GitHub] thrift pull request #1309: Use build tags to support context.

2017-07-17 Thread taozle
GitHub user taozle opened a pull request:

https://github.com/apache/thrift/pull/1309

Use build tags to support context.

As the comment in https://issues.apache.org/jira/browse/THRIFT-4236, this 
PR use build tags to support context in go1.7 above.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/taozle/thrift context

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1309.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1309


commit 0df5965eb2a35793f19de1b2696e3c4afb6b5132
Author: taozle 
Date:   2017-07-17T16:40:42Z

Use build tags to support context.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Resolved] (THRIFT-4239) Latest thrift breaks java build with handleRuntimeExceptions

2017-07-17 Thread Mario Emmenlauer (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer resolved THRIFT-4239.
--
Resolution: Fixed

> Latest thrift breaks java build with handleRuntimeExceptions
> 
>
> Key: THRIFT-4239
> URL: https://issues.apache.org/jira/browse/THRIFT-4239
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.11.0
> Environment: Ubuntu 16.04 LTS with Oracle Java 1.8 JDK
>Reporter: Mario Emmenlauer
>
> With the latest trunk I can no longer build my Java thrift example. I get an 
> error that handleRuntimeExceptions does not Override. It seems related to 
> these new additions in the generated Java code:
> {code}
> -  @Override
> -  protected boolean handleRuntimeExceptions() {
> -return false;
> -  }
> {code}
> With thrift 0.10.0 the method handleRuntimeExceptions (and the error) are not 
> present.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Closed] (THRIFT-4239) Latest thrift breaks java build with handleRuntimeExceptions

2017-07-17 Thread Mario Emmenlauer (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer closed THRIFT-4239.


Fixed, thanks.

> Latest thrift breaks java build with handleRuntimeExceptions
> 
>
> Key: THRIFT-4239
> URL: https://issues.apache.org/jira/browse/THRIFT-4239
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.11.0
> Environment: Ubuntu 16.04 LTS with Oracle Java 1.8 JDK
>Reporter: Mario Emmenlauer
>
> With the latest trunk I can no longer build my Java thrift example. I get an 
> error that handleRuntimeExceptions does not Override. It seems related to 
> these new additions in the generated Java code:
> {code}
> -  @Override
> -  protected boolean handleRuntimeExceptions() {
> -return false;
> -  }
> {code}
> With thrift 0.10.0 the method handleRuntimeExceptions (and the error) are not 
> present.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (THRIFT-4239) Latest thrift breaks java build with handleRuntimeExceptions

2017-07-17 Thread Mario Emmenlauer (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16089776#comment-16089776
 ] 

Mario Emmenlauer commented on THRIFT-4239:
--

Dear [~ctubbsii], thanks a lot!!! You are right, this is the issue! Dammit, 
that was not too easy to find for me, thanks a lot for your help.

> Latest thrift breaks java build with handleRuntimeExceptions
> 
>
> Key: THRIFT-4239
> URL: https://issues.apache.org/jira/browse/THRIFT-4239
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.11.0
> Environment: Ubuntu 16.04 LTS with Oracle Java 1.8 JDK
>Reporter: Mario Emmenlauer
>
> With the latest trunk I can no longer build my Java thrift example. I get an 
> error that handleRuntimeExceptions does not Override. It seems related to 
> these new additions in the generated Java code:
> {code}
> -  @Override
> -  protected boolean handleRuntimeExceptions() {
> -return false;
> -  }
> {code}
> With thrift 0.10.0 the method handleRuntimeExceptions (and the error) are not 
> present.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (THRIFT-4252) Cannot shutdown Java server when clients are still connected

2017-07-17 Thread Mario Emmenlauer (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer updated THRIFT-4252:
-
Description: 
I found issue https://issues.apache.org/jira/browse/THRIFT-2441 and I believe 
that the same problem still exists in the Java servers, and I'm affected by it. 
Short summary: I can not shut down the Java server (neither TSimpleServer nor 
TThreadedServer) while clients are still connected. That is pretty bad, because 
essentially the clients are not under by control, but they can essentially 
"block" server maintenance operations by blocking the shutdown.

*In more detail:* I have a Java TSimpleServer runnable in a thread running. The 
main thread eventually asks the server to stop(). But they seem to ignore the 
request. I checked the code of TSimpleServer.java and I'm under the impression 
that the innermost loop the server does not poll the variable stopped_ or does 
it? Looking at 
https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TSimpleServer.java
 from line 76:
{code}
  while (true) {
if (eventHandler_ != null) {
  eventHandler_.processContext(connectionContext, inputTransport, 
outputTransport);
}
if(!processor.process(inputProtocol, outputProtocol)) {
  break;
}
  }
{code}

I found that this loop is only interrupted if the client disconnects. I tried 
changing {{while(true)}} for {{while(!stopped_)}} but that did not help. I 
guess that one of the methods in the loop must be blocking.

  was:
I found issue https://issues.apache.org/jira/browse/THRIFT-2441 and I believe 
that the same problem still exists in the Java servers, and I'm affected by it. 
Short summary: I can not shut down the Java server (neither TSimpleServer nor 
TThreadedServer) while clients are still
connected. That is pretty bad, because essentially the clients are not under by 
control, but
they can essentially "block" server maintenance operations by blocking the 
shutdown.

In more detail:
I have a Java TSimpleServer runnable in a thread running. The main thread 
eventually asks the server to stop(). But they seem to ignore the request. I 
checked the code of TSimpleServer.java and I'm under the impression that the 
innermost loop the server does not poll the variable stopped_ or does it? 
Looking at 
https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TSimpleServer.java
 from line 76:
{code}
  while (true) {
if (eventHandler_ != null) {
  eventHandler_.processContext(connectionContext, inputTransport, 
outputTransport);
}
if(!processor.process(inputProtocol, outputProtocol)) {
  break;
}
  }
{code}

I found that this loop is only interrupted if the client disconnects. I tried 
changing `while(true)` for `while(!stopped_)` but that did not help. I guess 
that one of the methods in the loop must be blocking.


> Cannot shutdown Java server when clients are still connected
> 
>
> Key: THRIFT-4252
> URL: https://issues.apache.org/jira/browse/THRIFT-4252
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.10.0
>Reporter: Mario Emmenlauer
>
> I found issue https://issues.apache.org/jira/browse/THRIFT-2441 and I believe 
> that the same problem still exists in the Java servers, and I'm affected by 
> it. Short summary: I can not shut down the Java server (neither TSimpleServer 
> nor TThreadedServer) while clients are still connected. That is pretty bad, 
> because essentially the clients are not under by control, but they can 
> essentially "block" server maintenance operations by blocking the shutdown.
> *In more detail:* I have a Java TSimpleServer runnable in a thread running. 
> The main thread eventually asks the server to stop(). But they seem to ignore 
> the request. I checked the code of TSimpleServer.java and I'm under the 
> impression that the innermost loop the server does not poll the variable 
> stopped_ or does it? Looking at 
> https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TSimpleServer.java
>  from line 76:
> {code}
>   while (true) {
> if (eventHandler_ != null) {
>   eventHandler_.processContext(connectionContext, inputTransport, 
> outputTransport);
> }
> if(!processor.process(inputProtocol, outputProtocol)) {
>   break;
> }
>   }
> {code}
> I found that this loop is only interrupted if the client disconnects. I tried 
> changing {{while(true)}} for {{while(!stopped_)}} but that did not help. I 
> guess that one of the methods in the loop must be blocking.



--

[jira] [Created] (THRIFT-4252) Cannot shutdown Java server when clients are still connected

2017-07-17 Thread Mario Emmenlauer (JIRA)
Mario Emmenlauer created THRIFT-4252:


 Summary: Cannot shutdown Java server when clients are still 
connected
 Key: THRIFT-4252
 URL: https://issues.apache.org/jira/browse/THRIFT-4252
 Project: Thrift
  Issue Type: Bug
  Components: Java - Library
Affects Versions: 0.10.0
Reporter: Mario Emmenlauer


I found issue https://issues.apache.org/jira/browse/THRIFT-2441 and I believe 
that the same problem still exists in the Java servers, and I'm affected by it. 
Short summary: I can not shut down the Java server (neither TSimpleServer nor 
TThreadedServer) while clients are still
connected. That is pretty bad, because essentially the clients are not under by 
control, but
they can essentially "block" server maintenance operations by blocking the 
shutdown.

In more detail:
I have a Java TSimpleServer runnable in a thread running. The main thread 
eventually asks the server to stop(). But they seem to ignore the request. I 
checked the code of TSimpleServer.java and I'm under the impression that the 
innermost loop the server does not poll the variable stopped_ or does it? 
Looking at 
https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TSimpleServer.java
 from line 76:
{code}
  while (true) {
if (eventHandler_ != null) {
  eventHandler_.processContext(connectionContext, inputTransport, 
outputTransport);
}
if(!processor.process(inputProtocol, outputProtocol)) {
  break;
}
  }
{code}

I found that this loop is only interrupted if the client disconnects. I tried 
changing `while(true)` for `while(!stopped_)` but that did not help. I guess 
that one of the methods in the loop must be blocking.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)