[jira] [Updated] (THRIFT-4521) Cocoa compiler produces invalid code for recursive structs

[Yan Zhulanow (JIRA)]

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

Yan Zhulanow updated THRIFT-4521:
-
Description: 
{{Source:}}

{{---}}

{{struct Node {}}
 {{    1: string name;}}
 {{    2: list children;}}
 {{}}}

{{Generated code (partially, used Thrift 0.11.0):}}

{{-}}{{---}}{{---}}{{---}}{{---}}{{---}}{{}}{{---}}{{}}{{---}}{{}}

{{@interface Node : NSObject }}

{{@property (strong, nonatomic) NSString * name;}}
 {{@property (assign, nonatomic) BOOL nameIsSet;}}
 {{- (void) unsetName;}}

{{@property (strong, nonatomic) NSMutableArray * children;}}
 {{@property (assign, nonatomic) BOOL childrenIsSet;}}
 {{- (void) unsetChildren;}}

 

{{As you can see, NSMutableArray is not a valid type (NSMutableArray * was expected), and the code doesn't compile.}}

  was:
{{Source:}}

{{---}}

{{struct Node {}}
 {{    1: string name;}}
 {{    2: list children;}}
 {{}}}

{{Generated code (partially, used Thrift 0.11.0):}}

{{}}{{---}}{{---}}{{---}}{{---}}{{---}}{{}}{{---}}{{-}}

{{@interface Node : NSObject }}

{{@property (strong, nonatomic) NSString * name;}}
 {{@property (assign, nonatomic) BOOL nameIsSet;}}
 {{- (void) unsetName;}}

{{@property (strong, nonatomic) NSMutableArray * children;}}
 {{@property (assign, nonatomic) BOOL childrenIsSet;}}
 {{- (void) unsetChildren;}}

 

{{As you can see, NSMutableArray is not a valid type (NSMutableArray * was expected), and the code doesn't compile.}}


> Cocoa compiler produces invalid code for recursive structs
> --
>
> Key: THRIFT-4521
> URL: https://issues.apache.org/jira/browse/THRIFT-4521
> Project: Thrift
>  Issue Type: Bug
>  Components: Cocoa - Compiler
>Affects Versions: 0.11.0
>Reporter: Yan Zhulanow
>Priority: Major
>
> {{Source:}}
> {{---}}
> {{struct Node {}}
>  {{    1: string name;}}
>  {{    2: list children;}}
>  {{}}}
> {{Generated code (partially, used Thrift 0.11.0):}}
> {{-}}{{---}}{{---}}{{---}}{{---}}{{---}}{{}}{{---}}{{}}{{---}}{{}}
> {{@interface Node : NSObject }}
> {{@property (strong, nonatomic) NSString * name;}}
>  {{@property (assign, nonatomic) BOOL nameIsSet;}}
>  {{- (void) unsetName;}}
> {{@property (strong, nonatomic) NSMutableArray * children;}}
>  {{@property (assign, nonatomic) BOOL childrenIsSet;}}
>  {{- (void) unsetChildren;}}
>  
> {{As you can see, NSMutableArray is not a valid type 
> (NSMutableArray * was expected), and the code doesn't compile.}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4521) Cocoa compiler produces invalid code for recursive structs

[Yan Zhulanow (JIRA)]

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

Yan Zhulanow updated THRIFT-4521:
-
Description: 
{{Source:}}

{{---}}


 {{struct Node {}}
 {{    1: string name;}}
 {{    2: list children;}}
 {{}}}



{{Generated code (partially, used Thrift 0.11.0):}}

{{---}}{{---}}{{---}}{{---}}{{---}}{{---}}{{-}}


 {{@interface Node : NSObject }}

{{@property (strong, nonatomic) NSString * name;}}
 {{@property (assign, nonatomic) BOOL nameIsSet;}}
 {{- (void) unsetName;}}

{{@property (strong, nonatomic) NSMutableArray * children;}}
 {{@property (assign, nonatomic) BOOL childrenIsSet;}}
 {{- (void) unsetChildren;}}



 

{{As you can see, NSMutableArray is not a valid type (NSMutableArray * was expected), and the code doesn't compile.}}

  was:
{{Source:}}

{{```}}
{{struct Node {}}
{{    1: string name;}}
{{    2: list children;}}
{{}}}
{{```}}

{{Generated code (partially, used Thrift 0.11.0):}}

{{```}}
{{@interface Node : NSObject }}

{{@property (strong, nonatomic) NSString * name;}}
{{@property (assign, nonatomic) BOOL nameIsSet;}}
{{- (void) unsetName;}}

{{@property (strong, nonatomic) NSMutableArray * children;}}
{{@property (assign, nonatomic) BOOL childrenIsSet;}}
{{- (void) unsetChildren;}}
{{```}}

{{As you can see, NSMutableArray is not a valid type (NSMutableArray * was expected), and the code doesn't compile.}}


> Cocoa compiler produces invalid code for recursive structs
> --
>
> Key: THRIFT-4521
> URL: https://issues.apache.org/jira/browse/THRIFT-4521
> Project: Thrift
>  Issue Type: Bug
>  Components: Cocoa - Compiler
>Affects Versions: 0.11.0
>Reporter: Yan Zhulanow
>Priority: Major
>
> {{Source:}}
> {{---}}
>  {{struct Node {}}
>  {{    1: string name;}}
>  {{    2: list children;}}
>  {{}}}
> {{Generated code (partially, used Thrift 0.11.0):}}
> {{---}}{{---}}{{---}}{{---}}{{---}}{{---}}{{-}}
>  {{@interface Node : NSObject }}
> {{@property (strong, nonatomic) NSString * name;}}
>  {{@property (assign, nonatomic) BOOL nameIsSet;}}
>  {{- (void) unsetName;}}
> {{@property (strong, nonatomic) NSMutableArray * children;}}
>  {{@property (assign, nonatomic) BOOL childrenIsSet;}}
>  {{- (void) unsetChildren;}}
>  
> {{As you can see, NSMutableArray is not a valid type 
> (NSMutableArray * was expected), and the code doesn't compile.}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4521) Cocoa compiler produces invalid code for recursive structs

[Yan Zhulanow (JIRA)]

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

Yan Zhulanow updated THRIFT-4521:
-
Description: 
{{Source:}}

{{---}}

{{struct Node {}}
 {{    1: string name;}}
 {{    2: list children;}}
 {{}}}

{{Generated code (partially, used Thrift 0.11.0):}}

{{}}{{---}}{{---}}{{---}}{{---}}{{---}}{{}}{{---}}{{-}}

{{@interface Node : NSObject }}

{{@property (strong, nonatomic) NSString * name;}}
 {{@property (assign, nonatomic) BOOL nameIsSet;}}
 {{- (void) unsetName;}}

{{@property (strong, nonatomic) NSMutableArray * children;}}
 {{@property (assign, nonatomic) BOOL childrenIsSet;}}
 {{- (void) unsetChildren;}}

 

{{As you can see, NSMutableArray is not a valid type (NSMutableArray * was expected), and the code doesn't compile.}}

  was:
{{Source:}}

{{---}}


 {{struct Node {}}
 {{    1: string name;}}
 {{    2: list children;}}
 {{}}}



{{Generated code (partially, used Thrift 0.11.0):}}

{{---}}{{---}}{{---}}{{---}}{{---}}{{---}}{{-}}


 {{@interface Node : NSObject }}

{{@property (strong, nonatomic) NSString * name;}}
 {{@property (assign, nonatomic) BOOL nameIsSet;}}
 {{- (void) unsetName;}}

{{@property (strong, nonatomic) NSMutableArray * children;}}
 {{@property (assign, nonatomic) BOOL childrenIsSet;}}
 {{- (void) unsetChildren;}}



 

{{As you can see, NSMutableArray is not a valid type (NSMutableArray * was expected), and the code doesn't compile.}}


> Cocoa compiler produces invalid code for recursive structs
> --
>
> Key: THRIFT-4521
> URL: https://issues.apache.org/jira/browse/THRIFT-4521
> Project: Thrift
>  Issue Type: Bug
>  Components: Cocoa - Compiler
>Affects Versions: 0.11.0
>Reporter: Yan Zhulanow
>Priority: Major
>
> {{Source:}}
> {{---}}
> {{struct Node {}}
>  {{    1: string name;}}
>  {{    2: list children;}}
>  {{}}}
> {{Generated code (partially, used Thrift 0.11.0):}}
> {{}}{{---}}{{---}}{{---}}{{---}}{{---}}{{}}{{---}}{{-}}
> {{@interface Node : NSObject }}
> {{@property (strong, nonatomic) NSString * name;}}
>  {{@property (assign, nonatomic) BOOL nameIsSet;}}
>  {{- (void) unsetName;}}
> {{@property (strong, nonatomic) NSMutableArray * children;}}
>  {{@property (assign, nonatomic) BOOL childrenIsSet;}}
>  {{- (void) unsetChildren;}}
>  
> {{As you can see, NSMutableArray is not a valid type 
> (NSMutableArray * was expected), and the code doesn't compile.}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4521) Cocoa compiler produces invalid code for recursive structs

[Yan Zhulanow (JIRA)]

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

Yan Zhulanow updated THRIFT-4521:
-
Description: 
{{Source:}}

{{---}}

{{struct Node {}}
 {{    1: string name;}}
 {{    2: list children;}}
 {{}}}

{{Generated code (partially, used Thrift 0.11.0):}}

{{--}}{{---}}{{---}}{{---}}{{---}}{{---}}{{}}{{---}}{{}}{{--}}

{{@interface Node : NSObject }}

{{@property (strong, nonatomic) NSString * name;}}
 {{@property (assign, nonatomic) BOOL nameIsSet;}}
 {{- (void) unsetName;}}

{{@property (strong, nonatomic) NSMutableArray * children;}}
 {{@property (assign, nonatomic) BOOL childrenIsSet;}}
 {{- (void) unsetChildren;}}

 

{{As you can see, NSMutableArray is not a valid type (NSMutableArray * was expected), and the code doesn't compile.}}

  was:
{{Source:}}

{{---}}

{{struct Node {}}
 {{    1: string name;}}
 {{    2: list children;}}
 {{}}}

{{Generated code (partially, used Thrift 0.11.0):}}

{{-}}{{---}}{{---}}{{---}}{{---}}{{---}}{{}}{{---}}{{}}{{---}}{{}}

{{@interface Node : NSObject }}

{{@property (strong, nonatomic) NSString * name;}}
 {{@property (assign, nonatomic) BOOL nameIsSet;}}
 {{- (void) unsetName;}}

{{@property (strong, nonatomic) NSMutableArray * children;}}
 {{@property (assign, nonatomic) BOOL childrenIsSet;}}
 {{- (void) unsetChildren;}}

 

{{As you can see, NSMutableArray is not a valid type (NSMutableArray * was expected), and the code doesn't compile.}}


> Cocoa compiler produces invalid code for recursive structs
> --
>
> Key: THRIFT-4521
> URL: https://issues.apache.org/jira/browse/THRIFT-4521
> Project: Thrift
>  Issue Type: Bug
>  Components: Cocoa - Compiler
>Affects Versions: 0.11.0
>Reporter: Yan Zhulanow
>Priority: Major
>
> {{Source:}}
> {{---}}
> {{struct Node {}}
>  {{    1: string name;}}
>  {{    2: list children;}}
>  {{}}}
> {{Generated code (partially, used Thrift 0.11.0):}}
> {{--}}{{---}}{{---}}{{---}}{{---}}{{---}}{{}}{{---}}{{}}{{--}}
> {{@interface Node : NSObject }}
> {{@property (strong, nonatomic) NSString * name;}}
>  {{@property (assign, nonatomic) BOOL nameIsSet;}}
>  {{- (void) unsetName;}}
> {{@property (strong, nonatomic) NSMutableArray * children;}}
>  {{@property (assign, nonatomic) BOOL childrenIsSet;}}
>  {{- (void) unsetChildren;}}
>  
> {{As you can see, NSMutableArray is not a valid type 
> (NSMutableArray * was expected), and the code doesn't compile.}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4521) Cocoa compiler produces invalid code for recursive structs

[Yan Zhulanow (JIRA)]

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

Yan Zhulanow updated THRIFT-4521:
-
Description: 
Source:

```
struct Node {
1: string name;
2: list children;
}
```

Generated code (partially, used Thrift 0.11.0):

```
@interface Node : NSObject 

@property (strong, nonatomic) NSString * name;
@property (assign, nonatomic) BOOL nameIsSet;
- (void) unsetName;

@property (strong, nonatomic) NSMutableArray * children;
@property (assign, nonatomic) BOOL childrenIsSet;
- (void) unsetChildren;
```

As you can see, NSMutableArray is not a valid type (NSMutableArray * was expected), and the code doesn't compile.

  was:
+Source:+

{{struct Node {}}
 {{    1: string name;}}
 {{    2: list children;}}

+Generated code (partially, used Thrift 0.11.0):+

{{@interface Node : NSObject }}{{@property (strong, 
nonatomic) NSString * name;}}
{{ @property (assign, nonatomic) BOOL nameIsSet;}}

{{- (void) unsetName;}}

{{@property (strong, nonatomic) NSMutableArray * children;}}
{{ @property (assign, nonatomic) BOOL childrenIsSet;}}

{{- (void) unsetChildren;}}

As you can see, NSMutableArray is not a valid type (_NSMutableArray *_ expected), and the code doesn't compile.


> Cocoa compiler produces invalid code for recursive structs
> --
>
> Key: THRIFT-4521
> URL: https://issues.apache.org/jira/browse/THRIFT-4521
> Project: Thrift
>  Issue Type: Bug
>  Components: Cocoa - Compiler
>Affects Versions: 0.11.0
>Reporter: Yan Zhulanow
>Priority: Major
>
> Source:
> ```
> struct Node {
> 1: string name;
> 2: list children;
> }
> ```
> Generated code (partially, used Thrift 0.11.0):
> ```
> @interface Node : NSObject 
> @property (strong, nonatomic) NSString * name;
> @property (assign, nonatomic) BOOL nameIsSet;
> - (void) unsetName;
> @property (strong, nonatomic) NSMutableArray * children;
> @property (assign, nonatomic) BOOL childrenIsSet;
> - (void) unsetChildren;
> ```
> As you can see, NSMutableArray is not a valid type (NSMutableArray *> * was expected), and the code doesn't compile.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4521) Cocoa compiler produces invalid code for recursive structs

[Yan Zhulanow (JIRA)]

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

Yan Zhulanow updated THRIFT-4521:
-
Description: 
{{Source:}}

{{```}}
{{struct Node {}}
{{    1: string name;}}
{{    2: list children;}}
{{}}}
{{```}}

{{Generated code (partially, used Thrift 0.11.0):}}

{{```}}
{{@interface Node : NSObject }}

{{@property (strong, nonatomic) NSString * name;}}
{{@property (assign, nonatomic) BOOL nameIsSet;}}
{{- (void) unsetName;}}

{{@property (strong, nonatomic) NSMutableArray * children;}}
{{@property (assign, nonatomic) BOOL childrenIsSet;}}
{{- (void) unsetChildren;}}
{{```}}

{{As you can see, NSMutableArray is not a valid type (NSMutableArray * was expected), and the code doesn't compile.}}

  was:
Source:

```
struct Node {
1: string name;
2: list children;
}
```

Generated code (partially, used Thrift 0.11.0):

```
@interface Node : NSObject 

@property (strong, nonatomic) NSString * name;
@property (assign, nonatomic) BOOL nameIsSet;
- (void) unsetName;

@property (strong, nonatomic) NSMutableArray * children;
@property (assign, nonatomic) BOOL childrenIsSet;
- (void) unsetChildren;
```

As you can see, NSMutableArray is not a valid type (NSMutableArray * was expected), and the code doesn't compile.


> Cocoa compiler produces invalid code for recursive structs
> --
>
> Key: THRIFT-4521
> URL: https://issues.apache.org/jira/browse/THRIFT-4521
> Project: Thrift
>  Issue Type: Bug
>  Components: Cocoa - Compiler
>Affects Versions: 0.11.0
>Reporter: Yan Zhulanow
>Priority: Major
>
> {{Source:}}
> {{```}}
> {{struct Node {}}
> {{    1: string name;}}
> {{    2: list children;}}
> {{}}}
> {{```}}
> {{Generated code (partially, used Thrift 0.11.0):}}
> {{```}}
> {{@interface Node : NSObject }}
> {{@property (strong, nonatomic) NSString * name;}}
> {{@property (assign, nonatomic) BOOL nameIsSet;}}
> {{- (void) unsetName;}}
> {{@property (strong, nonatomic) NSMutableArray * children;}}
> {{@property (assign, nonatomic) BOOL childrenIsSet;}}
> {{- (void) unsetChildren;}}
> {{```}}
> {{As you can see, NSMutableArray is not a valid type 
> (NSMutableArray * was expected), and the code doesn't compile.}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4521) Cocoa compiler produces invalid code for recursive structs

[Yan Zhulanow (JIRA)]

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

Yan Zhulanow updated THRIFT-4521:
-
Description: 
+Source:+

{{struct Node {}}
 {{    1: string name;}}
 {{    2: list children;}}

+Generated code (partially, used Thrift 0.11.0):+

{{@interface Node : NSObject }}{{@property (strong, 
nonatomic) NSString * name;}}
{{ @property (assign, nonatomic) BOOL nameIsSet;}}

{{- (void) unsetName;}}

{{@property (strong, nonatomic) NSMutableArray * children;}}
{{ @property (assign, nonatomic) BOOL childrenIsSet;}}

{{- (void) unsetChildren;}}

As you can see, NSMutableArray is not a valid type (_NSMutableArray *_ expected), and the code doesn't compile.

  was:
+Source:+

{{struct Node {}}
{{    1: string name;}}
{{    2: list children;}}
{{ }}}

+Generated code (partially, used Thrift 0.11.0):+

{{@interface Node : NSObject }}{{@property (strong, 
nonatomic) NSString * name;}}
{{ @property (assign, nonatomic) BOOL nameIsSet;}}

{{- (void) unsetName;}}

{{@property (strong, nonatomic) NSMutableArray * children;}}
{{ @property (assign, nonatomic) BOOL childrenIsSet;}}

{{- (void) unsetChildren;}}

As you can see, NSMutableArray is not a valid type (_NSMutableArray *_ expected), and the code doesn't compile.


> Cocoa compiler produces invalid code for recursive structs
> --
>
> Key: THRIFT-4521
> URL: https://issues.apache.org/jira/browse/THRIFT-4521
> Project: Thrift
>  Issue Type: Bug
>  Components: Cocoa - Compiler
>Affects Versions: 0.11.0
>Reporter: Yan Zhulanow
>Priority: Major
>
> +Source:+
> {{struct Node {}}
>  {{    1: string name;}}
>  {{    2: list children;}}
> +Generated code (partially, used Thrift 0.11.0):+
> {{@interface Node : NSObject }}{{@property 
> (strong, nonatomic) NSString * name;}}
> {{ @property (assign, nonatomic) BOOL nameIsSet;}}
> {{- (void) unsetName;}}
> {{@property (strong, nonatomic) NSMutableArray * children;}}
> {{ @property (assign, nonatomic) BOOL childrenIsSet;}}
> {{- (void) unsetChildren;}}
> As you can see, NSMutableArray is not a valid type 
> (_NSMutableArray *_ expected), and the code doesn't compile.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (THRIFT-4521) Cocoa compiler produces invalid code for recursive structs

[Yan Zhulanow (JIRA)]

Yan Zhulanow created THRIFT-4521:


 Summary: Cocoa compiler produces invalid code for recursive structs
 Key: THRIFT-4521
 URL: https://issues.apache.org/jira/browse/THRIFT-4521
 Project: Thrift
  Issue Type: Bug
  Components: Cocoa - Compiler
Affects Versions: 0.11.0
Reporter: Yan Zhulanow


+Source:+

{{struct Node {}}
{{    1: string name;}}
{{    2: list children;}}
{{ }}}

+Generated code (partially, used Thrift 0.11.0):+

{{@interface Node : NSObject }}{{@property (strong, 
nonatomic) NSString * name;}}
{{ @property (assign, nonatomic) BOOL nameIsSet;}}

{{- (void) unsetName;}}

{{@property (strong, nonatomic) NSMutableArray * children;}}
{{ @property (assign, nonatomic) BOOL childrenIsSet;}}

{{- (void) unsetChildren;}}

As you can see, NSMutableArray is not a valid type (_NSMutableArray *_ expected), and the code doesn't compile.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4419) Rust framed transport cannot handle writes above 4096 bytes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4419:


GitHub user allengeorge opened a pull request:

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

THRIFT-4419: Fix bug where framed messages > 4K could not be read

Client: rs

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

$ git pull https://github.com/allengeorge/thrift thrift-4419

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

https://github.com/apache/thrift/pull/1508.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 #1508


commit f358ffbd997d33ad60bf4602c65d46ea6792386a
Author: Allen George 
Date:   2017-12-13T12:34:49Z

THRIFT-4419: Fix bug where framed messages > 4K could not be read
Client: rs




> Rust framed transport cannot handle writes above 4096 bytes
> ---
>
> Key: THRIFT-4419
> URL: https://issues.apache.org/jira/browse/THRIFT-4419
> Project: Thrift
>  Issue Type: Bug
>  Components: Rust - Library
>Reporter: Allen George
>Assignee: Allen George
>Priority: Critical
>
> Related to THRIFT-4390
> Description copied form there:
> While working on improving test coverage and fixing busted cross tests I 
> reworked the cpp test client to send binary in at size 0, 1, 2, 4, 6, 16, 
> ..., 131072 and after 4096 the rust server gave up.
> {noformat}
> 12, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 
> 127, 128])
> WARN:thrift::server::threaded: processor completed with error: TransportError 
> { kind: Unknown, message: "failed to write whole buffer" }
> Server process is successfully killed.
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] thrift pull request #1508: THRIFT-4419: Fix bug where framed messages > 4K c...

[allengeorge]

GitHub user allengeorge opened a pull request:

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

THRIFT-4419: Fix bug where framed messages > 4K could not be read

Client: rs

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

$ git pull https://github.com/allengeorge/thrift thrift-4419

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

https://github.com/apache/thrift/pull/1508.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 #1508


commit f358ffbd997d33ad60bf4602c65d46ea6792386a
Author: Allen George 
Date:   2017-12-13T12:34:49Z

THRIFT-4419: Fix bug where framed messages > 4K could not be read
Client: rs




---

[GitHub] thrift issue #1474: Recognize fbthrift TApplicationException codes

[jfarrell]

Github user jfarrell commented on the issue:

https://github.com/apache/thrift/pull/1474
  
Hi @yfeldblum, thanks for taking a look into this for us, appreciate your 
help. A new PR would be great that way it gives the ASF the needed audit trail 
of the origination of the pull request code contribution coming from Facebook 
to the ASF. 


---

[GitHub] thrift issue #1474: Recognize fbthrift TApplicationException codes

[yfeldblum]

Github user yfeldblum commented on the issue:

https://github.com/apache/thrift/pull/1474
  
@jfarrell Does Apache actually need a new PR originating from FB? Or is it 
sufficient for FB to okay this PR?


---

[jira] [Updated] (THRIFT-4515) Gracefully shutdown cross-test servers to fully test teardown

[James E. King, III (JIRA)]

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

James E. King, III updated THRIFT-4515:
---
Description: 
The cross test suite kills the server process after the client is done, see 
test/crosstest/run.py:_scoped, the process is killed. This means that we don't 
ever test teardown in any language in our cross tests.  Further, in some 
servers like the C++ TestServer, code at the end of main it sits in a TIGHT 
while loop unnecessarily causing CPU usage and slowing down the system.

There should be a signal (like SIGINT) that each server waits for, and on 
receiving that signal stops the thrift server cleanly.  This ensures we 
properly test teardown.
h4. Design

There is a new property in the tests.json file under server called 
"stop_signal".  If defined, the server understands how to stop when given this 
signal.  The cross test suite honors this.  Currently the cpp, d, and perl 
servers handle it properly.

When a server handles this signal, if the server dies unexpectedly or fails to 
stop that is considered an error.  The old behavior is applied to any legacy 
server which doesn't understand how to use a signal to stop.  In that case the 
server is killed with SIGKILL (unconditionally) and any result is ignored.

All test servers should be updated to support this new mechanism as soon as 
possible so that we improve test coverage of server stop / teardown code.

  was:
The cross test suite kills the server process after the client is done, see 
test/crosstest/run.py:_scoped, the process is killed. In the C++ TestServer 
code at the end of main it sits in a TIGHT while loop unnecessarily causing CPU 
usage and slowing down the system.

There should be a signal (like SIGINT) that each server waits for, and on 
receiving that signal stops the thrift server cleanly.  This ensures we 
properly test teardown.


> Gracefully shutdown cross-test servers to fully test teardown
> -
>
> Key: THRIFT-4515
> URL: https://issues.apache.org/jira/browse/THRIFT-4515
> Project: Thrift
>  Issue Type: Improvement
>  Components: Test Suite
>Affects Versions: 0.11.0
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Major
>
> The cross test suite kills the server process after the client is done, see 
> test/crosstest/run.py:_scoped, the process is killed. This means that we 
> don't ever test teardown in any language in our cross tests.  Further, in 
> some servers like the C++ TestServer, code at the end of main it sits in a 
> TIGHT while loop unnecessarily causing CPU usage and slowing down the system.
> There should be a signal (like SIGINT) that each server waits for, and on 
> receiving that signal stops the thrift server cleanly.  This ensures we 
> properly test teardown.
> h4. Design
> There is a new property in the tests.json file under server called 
> "stop_signal".  If defined, the server understands how to stop when given 
> this signal.  The cross test suite honors this.  Currently the cpp, d, and 
> perl servers handle it properly.
> When a server handles this signal, if the server dies unexpectedly or fails 
> to stop that is considered an error.  The old behavior is applied to any 
> legacy server which doesn't understand how to use a signal to stop.  In that 
> case the server is killed with SIGKILL (unconditionally) and any result is 
> ignored.
> All test servers should be updated to support this new mechanism as soon as 
> possible so that we improve test coverage of server stop / teardown code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (THRIFT-4515) Gracefully shutdown cross-test servers to fully test teardown

[James E. King, III (JIRA)]

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

James E. King, III edited comment on THRIFT-4515 at 3/16/18 8:28 PM:
-

So far I have done:
 * Teach C++ TestServer to ignore SIGPIPE, which allows it to exit gracefully 
for SSL based tests.
 * Have C++ TestServer block on a mutex in steady state.  When unblocked, it 
will stop the server.
 * Fixed the cpp TestServer to handle SIGINT, and unblock the mutex.
 * Added a server property in tests.json called stop_signal, the presence of 
which triggers a more controlled shutdown using a signal.
 * Have the cross test attempt to wait for server process to end gracefully 
when stopped using a signal (instead of the old behavior which is to terminate 
it rudely).
 * If the wait for server process times out (2 seconds), it is killed rudely; 
killing the server is now a cross test error as it means the server didn't stop 
gracefully (for servers that support stopping by signal).
 * Added dlang test server support for signal based test server shutdown.
 * Added perl test server support for signal based test server shutdown; 
curiously TServerSocker.pm did not define close() so I added it, and fixed the 
TSimpleServer to end properly.
 * Sadly all the remaining test servers also need this treatment, but this is a 
lot of work, so it is left for the future.
 * Fixed the C++ TSocket error message generator to put the path in the 
description when it is a path-based socket.

Working through the test suite now to find any issues this uncovered.


was (Author: jking3):
So far I have done:
 * Teach C++ TestServer to ignore SIGPIPE, which allows it to exit gracefully 
for SSL based tests.
 * Have C++ TestServer block on a mutex in steady state.  When unblocked, it 
will stop the server.
 * Fixed the cpp TestServer to handle SIGINT, and unblock the mutex.
 * Added a server property in tests.json called stop_signal, the presence of 
which triggers a more controlled shutdown using a signal.
 * Have the cross test attempt to wait for server process to end gracefully 
when stopped using a signal (instead of the old behavior which is to terminate 
it rudely).
 * If the wait for server process times out (2 seconds), it is killed rudely; 
killing the server is now a cross test error as it means the server didn't stop 
gracefully (for servers that support stopping by signal).
 * Added dlang test server support for signal based test server shutdown.
 * Sadly all the remaining test servers also need this treatment.

Working through the test suite now to find any issues this uncovered.

> Gracefully shutdown cross-test servers to fully test teardown
> -
>
> Key: THRIFT-4515
> URL: https://issues.apache.org/jira/browse/THRIFT-4515
> Project: Thrift
>  Issue Type: Improvement
>  Components: Test Suite
>Affects Versions: 0.11.0
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Major
>
> The cross test suite kills the server process after the client is done, see 
> test/crosstest/run.py:_scoped, the process is killed. In the C++ TestServer 
> code at the end of main it sits in a TIGHT while loop unnecessarily causing 
> CPU usage and slowing down the system.
> There should be a signal (like SIGINT) that each server waits for, and on 
> receiving that signal stops the thrift server cleanly.  This ensures we 
> properly test teardown.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (THRIFT-4515) Gracefully shutdown cross-test servers to fully test teardown

[James E. King, III (JIRA)]

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

James E. King, III edited comment on THRIFT-4515 at 3/16/18 5:45 PM:
-

So far I have done:
 * Teach C++ TestServer to ignore SIGPIPE, which allows it to exit gracefully 
for SSL based tests.
 * Have C++ TestServer block on a mutex in steady state.  When unblocked, it 
will stop the server.
 * Fixed the cpp TestServer to handle SIGINT, and unblock the mutex.
 * Added a server property in tests.json called stop_signal, the presence of 
which triggers a more controlled shutdown using a signal.
 * Have the cross test attempt to wait for server process to end gracefully 
when stopped using a signal (instead of the old behavior which is to terminate 
it rudely).
 * If the wait for server process times out (2 seconds), it is killed rudely; 
killing the server is now a cross test error as it means the server didn't stop 
gracefully (for servers that support stopping by signal).
 * Added dlang test server support for signal based test server shutdown.
 * Sadly all the remaining test servers also need this treatment.

Working through the test suite now to find any issues this uncovered.


was (Author: jking3):
So far I have:
 * Teach C++ TestServer to ignore SIGPIPE, which allows it to exit gracefully 
for SSL based tests.
 * Have C++ TestServer block on a mutex in steady state.  When unblocked, it 
will stop the server.
 * Fixed the cpp TestServer to handle SIGINT, and unblock the mutex.
 * Set the minimum required python version for cross testing to 3.3, because 
3.3 includes subprocess.wait(timeout=n)
 * Have the cross test attempt to wait for server process to end gracefully on 
SIGINT. 
 * If the wait for server process times out (2 seconds), it is killed 
(SIGKILL); killing the server is now a cross test error as it means the server 
didn't stop gracefully.

Working through the test suite now to find any issues this uncovered.

> Gracefully shutdown cross-test servers to fully test teardown
> -
>
> Key: THRIFT-4515
> URL: https://issues.apache.org/jira/browse/THRIFT-4515
> Project: Thrift
>  Issue Type: Improvement
>  Components: Test Suite
>Affects Versions: 0.11.0
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Major
>
> The cross test suite kills the server process after the client is done, see 
> test/crosstest/run.py:_scoped, the process is killed. In the C++ TestServer 
> code at the end of main it sits in a TIGHT while loop unnecessarily causing 
> CPU usage and slowing down the system.
> There should be a signal (like SIGINT) that each server waits for, and on 
> receiving that signal stops the thrift server cleanly.  This ensures we 
> properly test teardown.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4496) Dealing with language keywords in Thrift (e.g. service method names)

[Vera Filippova (JIRA)]

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

Vera Filippova commented on THRIFT-4496:


 Here is what I plan to do next. Could you please tell me if I'm on a right 
track?

1). Existing generators don't tweak keywords
I can see that many generators (e.g. cpp, java, py) don't modify identifiers 
from the parsed syntax tree node. This is 
[t_cpp_generator::function_signature|https://github.com/apache/thrift/blob/master/compiler/cpp/src/thrift/generate/t_cpp_generator.cc#L4353]:
{code:java}
return "void " + prefix + tfunction->get_name() + "(" + type_name(ttype)
+ (name_params ? "& _return" : "& /* _return */")
+ argument_list(arglist, name_params, true) + ")";
{code}
If this is a bug, as you say, I can write a functional test under 
thrift/compiler/cpp/tests/cpp. The test will create a syntax tree node for 
function/enum/service etc with keyword name, generate output, then compare it 
with a sample with a tweaked name.

2). How to move screening for keywords from a lexical analyzer to generators
Using no common methods to validate/modify an identifier also doesn't give me a 
convenient place to insert a check if an id is a keyword. So the easiest way to 
do it I think is to iterate over the whole syntax tree in the base t_generator 
and check each element with a name against the existing "full" keyword set 
before the generation begins. Then as soon as any child generator can deal with 
keywords in its language, it can turn off the check.

3). Testing the refactoring of keywords screening
The most convenient way for me to test that I didn't break the current behavior 
would be to generate sample thrift files, each file containing one thrift 
element (struct/function/enum etc) with a keyword name. Now if I generate a 
thrift file for each element with each keyword in a list, then run "thrift 
--gen language" for all languages on these files and expect it to fail every 
time, I can be pretty sure my change is covered.
As I understand, there is no place in a current build system where such testing 
script can be built in. There are functional tests for compilers, but each test 
tests only one language. Also I found 
[test/py/explicit_module/runtest.sh|https://github.com/apache/thrift/blob/master/test/py/explicit_module/runtest.sh]
 which does exactly this but only for one case: enum named "from" for py 
generator
{code:java}
../../../compiler/cpp/thrift --gen py test3.thrift && exit 1  # Fail since 
test3.thrift has python keywords
{code}
but It seems this script isn't called from a build system at all?

Can this kind of a testing script fit into the existing testing framework? If 
not, I would do the same in a functional test, but then, can I have one test 
for several languages?

> Dealing with language keywords in Thrift (e.g. service method names)
> 
>
> Key: THRIFT-4496
> URL: https://issues.apache.org/jira/browse/THRIFT-4496
> Project: Thrift
>  Issue Type: New Feature
>  Components: Compiler (General)
>Reporter: Vera Filippova
>Priority: Minor
>
> Apache Thrift compiler doesn't allow to use keywords in any of supported 
> languages as field names. However, there are other compilers, like Scrooge, 
> which do allow using some keywords as field identifiers, which leads to 
> incompatibility.
> Assume we had a service with 'delete' method, with Java code generated by 
> Scrooge. Now we'd like to generate Python code with Apache Thrift, but 
> encounter an error because of the 'delete' keyword.
> I understand that using only Apache Thrift compiler, a user will never 
> encounter this problem, but I think enabling keywords by request seems 
> feasible.
> h1. Proposal
> It's possible to tweak keywords on code generation stage, e.g. use 'delete_' 
> as a name of a generated function instead of 'delete', then use the original 
> method name for a protocol message: writeMethodBegin('delete').
> This feature could be enabled with an additional flag, e.g. --screen-keywords.
> I have a draft for python generator here [https://github.com/nsrtvwls/thrift]
> The questions are, is this functionality welcome? If yes, would it require to 
> have it supported for all languages?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] thrift issue #1480: [nodejs] Fix issue with connection failures silently fai...

[dorilla]

Github user dorilla commented on the issue:

https://github.com/apache/thrift/pull/1480
  
Apologies, I haven't had the time to update this ticket. I fully intend to, 
just trying to find the time.


---

[jira] [Commented] (THRIFT-4476) Typecasting problem on list items

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4476:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1496
  
If there's a way to fix it in the compiler so that it works properly, 
that's much better.  Having compiler-version-specific branches in the thrift 
compiler to handle floating point oddities like this is fine.  Carrying the C++ 
compiler identifier down through the build system and pass into the tests as an 
argument/option/variable should really be avoided.


> Typecasting problem on list items
> -
>
> Key: THRIFT-4476
> URL: https://issues.apache.org/jira/browse/THRIFT-4476
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.11.0
>Reporter: Ozan Can Altiok
>Priority: Major
>
> I was trying to add the following into a thrift interface file.
> {{const list timeCoefficients = [24, 60, 60, 1000, 1000, 1000]}}
> With the definition given above the {{.thrift}} file compiled properly. 
> However, I noticed that in Python, the items in {{timeCoefficients}} are 
> considered to be integer although the list has been defined to include items 
> of {{double}} type. Then I modified the definition as given below to make 
> sure all the items are of type {{double}}. 
> {{const list timeCoefficients = [24.0, 60.0, 60.0, 1000.0, 1000.0, 
> 1000.0]}}
> After the change, I ran into the following error during compilation.
> {{[ERROR] .../TimeCoefficients.java:[402,48] error: no suitable method found 
> for add(int)}}
>  {{[ERROR] method Collection.add(Double) is not applicable}}
>  {{[ERROR] (argument mismatch; int cannot be converted to Double)}}
>  {{[ERROR] method List.add(Double) is not applicable}}
>  {{[ERROR] (argument mismatch; int cannot be converted to Double)}}
> Next, I changed the line as follows and the compilation became successful.
> {{const list timeCoefficients = [24.1, 60.1, 60.1, 1000.1, 1000.1, 
> 1000.1]}}
> When I reviewed the generated Java source files, I discovered that
> {{const list timeCoefficients = [24, 60, 60, 1000, 1000, 1000]}}
> compiles to
> {{public static final java.util.List timeCoefficients = new 
> java.util.ArrayList();}}
> {{static {}}
> {{  timeCoefficients.add((double)24);}}
>  {{  timeCoefficients.add((double)60);}}
>  {{  timeCoefficients.add((double)60);}}
>  {{  timeCoefficients.add((double)1000);}}
>  {{  timeCoefficients.add((double)1000);}}
>  {{  timeCoefficients.add((double)1000);}}
> {{}}}
> whilst
> {{const list timeCoefficients = [24.0, 60.0, 60.0, 1000.0, 1000.0, 
> 1000.0]}}
> compiles to
> {{public static final java.util.List timeCoefficients = new 
> java.util.ArrayList();}}
> {{static {}}
> {{  timeCoefficients.add(24);}}
> {{  timeCoefficients.add(60);}}
> {{  timeCoefficients.add(60);}}
> {{  timeCoefficients.add(1000);}}
> {{  timeCoefficients.add(1000);}}
> {{  timeCoefficients.add(1000);}}
> {{}}}
> which leads to an error.
> When I modified this line as follows
> {{const list timeCoefficients = [24.1, 60.1, 60.1, 1000.1, 1000.1, 
> 1000.1]}}
> this line compiled to
> {{public static final java.util.List timeCoefficients = new 
> java.util.ArrayList();}}
> {{static {}}
> {{  timeCoefficients.add(24.1);}}
> {{  timeCoefficients.add(60.1);}}
> {{  timeCoefficients.add(60.1);}}
> {{  timeCoefficients.add(1000.1);}}
> {{  timeCoefficients.add(1000.1);}}
> {{  timeCoefficients.add(1000.1);}}
> {{}}}
> My guess is that, even if I put {{.0}} at the end of each numeric constant, 
> on the Java side, Thrift compiler considers them to be {{double}} and does no 
> typecasts. However, the {{.0}} s are getting lost somewhere and the items 
> become integers in the generated Java code. Thus, when it comes to populating 
> the array, Java cannot succeed. {{Double}} s cannot be unboxed to integer and 
> Java thinks {{int}} and {{Double}} are not related.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] thrift issue #1496: THRIFT-4476: Typecasting problem on list items (+ low pr...

[jeking3]

Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1496
  
If there's a way to fix it in the compiler so that it works properly, 
that's much better.  Having compiler-version-specific branches in the thrift 
compiler to handle floating point oddities like this is fine.  Carrying the C++ 
compiler identifier down through the build system and pass into the tests as an 
argument/option/variable should really be avoided.


---

[jira] [Commented] (THRIFT-4476) Typecasting problem on list items

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4476:


Github user ozymaxx commented on the issue:

https://github.com/apache/thrift/pull/1496
  
@jeking3 or another alternative path to go: emitting double can depend on 
the msvc compiler version. If the compiler version is 2013 or less, we can 
ignore using fixed. 


> Typecasting problem on list items
> -
>
> Key: THRIFT-4476
> URL: https://issues.apache.org/jira/browse/THRIFT-4476
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.11.0
>Reporter: Ozan Can Altiok
>Priority: Major
>
> I was trying to add the following into a thrift interface file.
> {{const list timeCoefficients = [24, 60, 60, 1000, 1000, 1000]}}
> With the definition given above the {{.thrift}} file compiled properly. 
> However, I noticed that in Python, the items in {{timeCoefficients}} are 
> considered to be integer although the list has been defined to include items 
> of {{double}} type. Then I modified the definition as given below to make 
> sure all the items are of type {{double}}. 
> {{const list timeCoefficients = [24.0, 60.0, 60.0, 1000.0, 1000.0, 
> 1000.0]}}
> After the change, I ran into the following error during compilation.
> {{[ERROR] .../TimeCoefficients.java:[402,48] error: no suitable method found 
> for add(int)}}
>  {{[ERROR] method Collection.add(Double) is not applicable}}
>  {{[ERROR] (argument mismatch; int cannot be converted to Double)}}
>  {{[ERROR] method List.add(Double) is not applicable}}
>  {{[ERROR] (argument mismatch; int cannot be converted to Double)}}
> Next, I changed the line as follows and the compilation became successful.
> {{const list timeCoefficients = [24.1, 60.1, 60.1, 1000.1, 1000.1, 
> 1000.1]}}
> When I reviewed the generated Java source files, I discovered that
> {{const list timeCoefficients = [24, 60, 60, 1000, 1000, 1000]}}
> compiles to
> {{public static final java.util.List timeCoefficients = new 
> java.util.ArrayList();}}
> {{static {}}
> {{  timeCoefficients.add((double)24);}}
>  {{  timeCoefficients.add((double)60);}}
>  {{  timeCoefficients.add((double)60);}}
>  {{  timeCoefficients.add((double)1000);}}
>  {{  timeCoefficients.add((double)1000);}}
>  {{  timeCoefficients.add((double)1000);}}
> {{}}}
> whilst
> {{const list timeCoefficients = [24.0, 60.0, 60.0, 1000.0, 1000.0, 
> 1000.0]}}
> compiles to
> {{public static final java.util.List timeCoefficients = new 
> java.util.ArrayList();}}
> {{static {}}
> {{  timeCoefficients.add(24);}}
> {{  timeCoefficients.add(60);}}
> {{  timeCoefficients.add(60);}}
> {{  timeCoefficients.add(1000);}}
> {{  timeCoefficients.add(1000);}}
> {{  timeCoefficients.add(1000);}}
> {{}}}
> which leads to an error.
> When I modified this line as follows
> {{const list timeCoefficients = [24.1, 60.1, 60.1, 1000.1, 1000.1, 
> 1000.1]}}
> this line compiled to
> {{public static final java.util.List timeCoefficients = new 
> java.util.ArrayList();}}
> {{static {}}
> {{  timeCoefficients.add(24.1);}}
> {{  timeCoefficients.add(60.1);}}
> {{  timeCoefficients.add(60.1);}}
> {{  timeCoefficients.add(1000.1);}}
> {{  timeCoefficients.add(1000.1);}}
> {{  timeCoefficients.add(1000.1);}}
> {{}}}
> My guess is that, even if I put {{.0}} at the end of each numeric constant, 
> on the Java side, Thrift compiler considers them to be {{double}} and does no 
> typecasts. However, the {{.0}} s are getting lost somewhere and the items 
> become integers in the generated Java code. Thus, when it comes to populating 
> the array, Java cannot succeed. {{Double}} s cannot be unboxed to integer and 
> Java thinks {{int}} and {{Double}} are not related.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] thrift issue #1496: THRIFT-4476: Typecasting problem on list items (+ low pr...

[ozymaxx]

Github user ozymaxx commented on the issue:

https://github.com/apache/thrift/pull/1496
  
@jeking3 or another alternative path to go: emitting double can depend on 
the msvc compiler version. If the compiler version is 2013 or less, we can 
ignore using fixed. 


---

[jira] [Commented] (THRIFT-4476) Typecasting problem on list items

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-4476:


Github user ozymaxx commented on the issue:

https://github.com/apache/thrift/pull/1496
  
@jeking3 , I will now re-enable the tests. But please note that the problem 
is at the C++ compiler level. The pre-2015 versions of the Visual Studio C++ 
compilers uses a different parsing and formatting algorithms on floating point 
numbers. Check this link out: 
https://blogs.msdn.microsoft.com/vcblog/2014/06/18/c-runtime-crt-features-fixes-and-breaking-changes-in-visual-studio-14-ctp1/
 (go to the title "Floating Point Formatting and Parsing Correctness")

Another article describing the issue: 
http://www.exploringbinary.com/visual-c-plus-plus-strtod-still-broken/
The comment made on the article, by a Visual Studio dev. team member: 
http://www.exploringbinary.com/visual-c-plus-plus-strtod-still-broken/#comment-9403

In the light of these, the best solution seems checking the compiler 
version, and doing the tests accordingly. 


> Typecasting problem on list items
> -
>
> Key: THRIFT-4476
> URL: https://issues.apache.org/jira/browse/THRIFT-4476
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.11.0
>Reporter: Ozan Can Altiok
>Priority: Major
>
> I was trying to add the following into a thrift interface file.
> {{const list timeCoefficients = [24, 60, 60, 1000, 1000, 1000]}}
> With the definition given above the {{.thrift}} file compiled properly. 
> However, I noticed that in Python, the items in {{timeCoefficients}} are 
> considered to be integer although the list has been defined to include items 
> of {{double}} type. Then I modified the definition as given below to make 
> sure all the items are of type {{double}}. 
> {{const list timeCoefficients = [24.0, 60.0, 60.0, 1000.0, 1000.0, 
> 1000.0]}}
> After the change, I ran into the following error during compilation.
> {{[ERROR] .../TimeCoefficients.java:[402,48] error: no suitable method found 
> for add(int)}}
>  {{[ERROR] method Collection.add(Double) is not applicable}}
>  {{[ERROR] (argument mismatch; int cannot be converted to Double)}}
>  {{[ERROR] method List.add(Double) is not applicable}}
>  {{[ERROR] (argument mismatch; int cannot be converted to Double)}}
> Next, I changed the line as follows and the compilation became successful.
> {{const list timeCoefficients = [24.1, 60.1, 60.1, 1000.1, 1000.1, 
> 1000.1]}}
> When I reviewed the generated Java source files, I discovered that
> {{const list timeCoefficients = [24, 60, 60, 1000, 1000, 1000]}}
> compiles to
> {{public static final java.util.List timeCoefficients = new 
> java.util.ArrayList();}}
> {{static {}}
> {{  timeCoefficients.add((double)24);}}
>  {{  timeCoefficients.add((double)60);}}
>  {{  timeCoefficients.add((double)60);}}
>  {{  timeCoefficients.add((double)1000);}}
>  {{  timeCoefficients.add((double)1000);}}
>  {{  timeCoefficients.add((double)1000);}}
> {{}}}
> whilst
> {{const list timeCoefficients = [24.0, 60.0, 60.0, 1000.0, 1000.0, 
> 1000.0]}}
> compiles to
> {{public static final java.util.List timeCoefficients = new 
> java.util.ArrayList();}}
> {{static {}}
> {{  timeCoefficients.add(24);}}
> {{  timeCoefficients.add(60);}}
> {{  timeCoefficients.add(60);}}
> {{  timeCoefficients.add(1000);}}
> {{  timeCoefficients.add(1000);}}
> {{  timeCoefficients.add(1000);}}
> {{}}}
> which leads to an error.
> When I modified this line as follows
> {{const list timeCoefficients = [24.1, 60.1, 60.1, 1000.1, 1000.1, 
> 1000.1]}}
> this line compiled to
> {{public static final java.util.List timeCoefficients = new 
> java.util.ArrayList();}}
> {{static {}}
> {{  timeCoefficients.add(24.1);}}
> {{  timeCoefficients.add(60.1);}}
> {{  timeCoefficients.add(60.1);}}
> {{  timeCoefficients.add(1000.1);}}
> {{  timeCoefficients.add(1000.1);}}
> {{  timeCoefficients.add(1000.1);}}
> {{}}}
> My guess is that, even if I put {{.0}} at the end of each numeric constant, 
> on the Java side, Thrift compiler considers them to be {{double}} and does no 
> typecasts. However, the {{.0}} s are getting lost somewhere and the items 
> become integers in the generated Java code. Thus, when it comes to populating 
> the array, Java cannot succeed. {{Double}} s cannot be unboxed to integer and 
> Java thinks {{int}} and {{Double}} are not related.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] thrift issue #1496: THRIFT-4476: Typecasting problem on list items (+ low pr...

[ozymaxx]

Github user ozymaxx commented on the issue:

https://github.com/apache/thrift/pull/1496
  
@jeking3 , I will now re-enable the tests. But please note that the problem 
is at the C++ compiler level. The pre-2015 versions of the Visual Studio C++ 
compilers uses a different parsing and formatting algorithms on floating point 
numbers. Check this link out: 
https://blogs.msdn.microsoft.com/vcblog/2014/06/18/c-runtime-crt-features-fixes-and-breaking-changes-in-visual-studio-14-ctp1/
 (go to the title "Floating Point Formatting and Parsing Correctness")

Another article describing the issue: 
http://www.exploringbinary.com/visual-c-plus-plus-strtod-still-broken/
The comment made on the article, by a Visual Studio dev. team member: 
http://www.exploringbinary.com/visual-c-plus-plus-strtod-still-broken/#comment-9403

In the light of these, the best solution seems checking the compiler 
version, and doing the tests accordingly. 


---

[jira] [Created] (THRIFT-4520) Modernize JS/node

[Philip Frank (JIRA)]

Philip Frank created THRIFT-4520:


 Summary: Modernize JS/node
 Key: THRIFT-4520
 URL: https://issues.apache.org/jira/browse/THRIFT-4520
 Project: Thrift
  Issue Type: Wish
  Components: JavaScript - Compiler, JavaScript - Library, Node.js - 
Compiler, Node.js - Library
Reporter: Philip Frank


This is just a wishlist for now, I consider tackling some of the points when I 
have downtime. As [~jking3] proposed, these incompatible changes would live in 
separate "js2" and "node2" directories. Feedback and additions are welcome!

* De-duplicte implementations of JS and node, including:
 ** Thrift.TJSONProtocol
 ** Thrift.MultiplexProtocol
 ** Thrift.Type
 ** Thrift.MessageType
 ** various Exception types
* Drop support for synchronous service calls (js+node), jquery based calls (js) 
and maybe even async "callback as last argument" calls; embrace Promise as 
return value
* integrate JS with "make cross" test suite, possibly using karma and 
chrome-headless, drop grunt/phantom-based test workflow
* Bonus: publish smaller npm packages for browser and node, which include only 
the lib



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (THRIFT-4516) Add support for go 1.10

[Can Celasun (JIRA)]

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

Can Celasun resolved THRIFT-4516.
-
   Resolution: Fixed
Fix Version/s: 0.12.0

> Add support for go 1.10
> ---
>
> Key: THRIFT-4516
> URL: https://issues.apache.org/jira/browse/THRIFT-4516
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Library
>Affects Versions: 0.11.0
> Environment: ubuntu-artful (using go 1.10 instead of 1.9)
>Reporter: James E. King, III
>Assignee: Can Celasun
>Priority: Major
> Fix For: 0.12.0
>
>
> Currently go 1.10 has additional type checking on format strings that prevent 
> thrift from compiling and running tests.  We are limited to go 1.9 until this 
> is resolved.
> Example:
> {noformat}
> thrift/protocol_test.go:442: Errorf format %s has arg thelen of wrong type int
> thrift/protocol_test.go:447: Errorf format %q has arg v of wrong type float64
> thrift/protocol_test.go:451: Errorf format %q has arg v of wrong type float64
> thrift/protocol_test.go:454: Errorf format %q has arg value of wrong type 
> float64
> thrift/protocol_test.go:482: Errorf format %s has arg thelen of wrong type int
> thrift/protocol_test.go:491: Errorf format %d has arg v of wrong type string
> gopath/src/dontexportrwtest/compile_test.go:32: Sprintf format %v arg s.read 
> is a func value, not called
> gopath/src/dontexportrwtest/compile_test.go:33: Sprintf format %v arg s.write 
> is a func value, not called
> gopath/src/dontexportrwtest/compile_test.go:36: Sprintf format %v arg is.read 
> is a func value, not called
> gopath/src/dontexportrwtest/compile_test.go:37: Sprintf format %v arg 
> is.write is a func value, not called{noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)