[jira] [Commented] (THRIFT-3276) Binary data does not decode correctly using the TJSONProtocol when the base64 encoded data is padded.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3276:


GitHub user nsuke opened a pull request:

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

THRIFT-3276 Binary data does not decode correctly using the TJSONProt…

…ocol when the base64 encoded data is padded.

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

$ git pull https://github.com/nsuke/thrift THRIFT-3276

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

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


commit aa8ec9ef94372ca8035b2c90d7efa07ddf326880
Author: Nobuaki Sukegawa 
Date:   2015-10-10T01:44:07Z

THRIFT-3276 Binary data does not decode correctly using the TJSONProtocol 
when the base64 encoded data is padded.




> Binary data does not decode correctly using the TJSONProtocol when the base64 
> encoded data is padded.
> -
>
> Key: THRIFT-3276
> URL: https://issues.apache.org/jira/browse/THRIFT-3276
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library, Java - Library
>Affects Versions: 0.9.1
>Reporter: Steve Niemitz
>
> If the base64 encoded JSON string has padding bytes at the end, the resulting 
> binary data returned in the thrift object ends up with extra padding bytes 
> (0xFF) at the end.
> It seems like this is caused by the TJSONProtocol [using the padded 
> length|https://github.com/apache/thrift/blob/0.9.1/lib/java/src/org/apache/thrift/protocol/TJSONProtocol.java#L760]
>  when it tries to decode the last chunk, which results in the '=' being 
> converted into binary data.  The DECODE_TABLE defaults to -1 (0xFF), which is 
> how it gets into the final output.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (THRIFT-3377) Deep copy is actually shallow when using typedef members

[Vincent Dumont (JIRA)]

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

Vincent Dumont updated THRIFT-3377:
---
Description: 
Consider the following structures:

{code:title=thrift|borderStyle=solid}
typedef set sset;

struct Test {
  1: set myset;
}

struct Test2 {
  1: sset myset;
}
{code}

The generated code for Test's copy constructor looks fine, it deep copies the 
set. However, Test2, which should be equivalent, actually does not deep-copy 
the set and instead simply does a shallow assignment like if it was a POD type. 

{code:title=Test.java|borderStyle=solid}
  /** 
   * Performs a deep copy on other.
   */
  public Test(Test other) {
if (other.isSetMyset()) {
  Set __this__myset = new HashSet(other.myset);
  this.myset = __this__myset;
}   
  }
{code}

VS

{code:title=Test2.java|borderStyle=solid}
  /**
   * Performs a deep copy on other.
   */
  public Test2(Test2 other) {
if (other.isSetMyset()) {
  this.myset = other.myset; // Not deep...
}
  }
{code}

  was:
Consider the following structures:

{code:title=thrift|borderStyle=solid}
typedef set sset;

struct Test {
  1: set myset;
}

struct Test2 {
  1: sset myset;
}
{code}

The generate code for Test's copy constructor looks fine, it deep copies the 
set. However, Test2, which should be equivalent, actually does not deep-copy 
the set and instead simply does a shallow assignment like if it was a POD type. 

{code:title=Test.java|borderStyle=solid}
  /** 
   * Performs a deep copy on other.
   */
  public Test(Test other) {
if (other.isSetMyset()) {
  Set __this__myset = new HashSet(other.myset);
  this.myset = __this__myset;
}   
  }
{code}

VS

{code:title=Test2.java|borderStyle=solid}
  /**
   * Performs a deep copy on other.
   */
  public Test2(Test2 other) {
if (other.isSetMyset()) {
  this.myset = other.myset; // Not deep...
}
  }
{code}


> Deep copy is actually shallow when using typedef members
> 
>
> Key: THRIFT-3377
> URL: https://issues.apache.org/jira/browse/THRIFT-3377
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.9.2
>Reporter: Vincent Dumont
>
> Consider the following structures:
> {code:title=thrift|borderStyle=solid}
> typedef set sset;
> struct Test {
>   1: set myset;
> }
> struct Test2 {
>   1: sset myset;
> }
> {code}
> The generated code for Test's copy constructor looks fine, it deep copies the 
> set. However, Test2, which should be equivalent, actually does not deep-copy 
> the set and instead simply does a shallow assignment like if it was a POD 
> type. 
> {code:title=Test.java|borderStyle=solid}
>   /** 
>* Performs a deep copy on other.
>*/
>   public Test(Test other) {
> if (other.isSetMyset()) {
>   Set __this__myset = new HashSet(other.myset);
>   this.myset = __this__myset;
> }   
>   }
> {code}
> VS
> {code:title=Test2.java|borderStyle=solid}
>   /**
>* Performs a deep copy on other.
>*/
>   public Test2(Test2 other) {
> if (other.isSetMyset()) {
>   this.myset = other.myset; // Not deep...
> }
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (THRIFT-3377) Deep copy is actually shallow when using typedef members

[Vincent Dumont (JIRA)]

Vincent Dumont created THRIFT-3377:
--

 Summary: Deep copy is actually shallow when using typedef members
 Key: THRIFT-3377
 URL: https://issues.apache.org/jira/browse/THRIFT-3377
 Project: Thrift
  Issue Type: Bug
  Components: Java - Compiler
Affects Versions: 0.9.2
Reporter: Vincent Dumont


Consider the following structures:

{code:title=thrift|borderStyle=solid}
typedef set sset;

struct Test {
  1: set myset;
}

struct Test2 {
  1: sset myset;
}
{code}

The generate code for Test's copy constructor looks fine, it deep copies the 
set. However, Test2, which should be equivalent, actually does not deep-copy 
the set and instead simply does a shallow assignment like if it was a POD type. 

{code:title=Test.java|borderStyle=solid}
  /** 
   * Performs a deep copy on other.
   */
  public Test(Test other) {
if (other.isSetMyset()) {
  Set __this__myset = new HashSet(other.myset);
  this.myset = __this__myset;
}   
  }
{code}

VS

{code:title=Test2.java|borderStyle=solid}
  /**
   * Performs a deep copy on other.
   */
  public Test2(Test2 other) {
if (other.isSetMyset()) {
  this.myset = other.myset; // Not deep...
}
  }
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (THRIFT-3378) c_glib service does not handle negative Thrift byte values correctly

[Nobuaki Sukegawa (JIRA)]

Nobuaki Sukegawa created THRIFT-3378:


 Summary: c_glib service does not handle negative Thrift byte 
values correctly
 Key: THRIFT-3378
 URL: https://issues.apache.org/jira/browse/THRIFT-3378
 Project: Thrift
  Issue Type: Bug
  Components: C glib - Compiler
Reporter: Nobuaki Sukegawa


There's a problematic type cast in generated c_glib service code that treat the 
sign bit of gint8 as normal bit (i.e. 128).
The problem is illustrated as follows.

{code}
int i = 0;
users_handler_func((*gint8));  // Suppose this function tries to set i to -100
store_handler_result(i); // This stores 156, not -100
{code}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3379) Potential out of range panic in Go JSON protocols

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3379:


GitHub user nsuke opened a pull request:

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

THRIFT-3379 Potential out of range panic in Go JSON protocols



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

$ git pull https://github.com/nsuke/thrift THRIFT-3379

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

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


commit 95a84dc5f4c348bd119368ba0440a663fa1c5d75
Author: Nobuaki Sukegawa 
Date:   2015-10-10T02:28:54Z

THRIFT-3379 Potential out of range panic in Go JSON protocols




>  Potential out of range panic in Go JSON protocols
> --
>
> Key: THRIFT-3379
> URL: https://issues.apache.org/jira/browse/THRIFT-3379
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Library
>Reporter: Nobuaki Sukegawa
>
> Slice length check is incorrect and in rare occasions it can cause run-time 
> panic.
> {code}
>  } else if len(f) >= 0 && f[0] == JSON_NULL[0] {
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (THRIFT-3377) Deep copy is actually shallow when using typedef members

[Vincent Dumont (JIRA)]

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

Vincent Dumont updated THRIFT-3377:
---
Description: 
Consider the following structures:

{code:title=thrift|borderStyle=solid}
typedef set sset;

struct Test {
  1: set myset;
}

struct Test2 {
  1: sset myset;
}
{code}

The generated code for Test's copy constructor looks fine, it deep copies the 
set. However, Test2, which should be equivalent, actually does not deep-copy 
the set and instead simply does a shallow assignment like if it was a POD type. 

{code:title=Test.java -- deep|borderStyle=solid}
  /** 
   * Performs a deep copy on other.
   */
  public Test(Test other) {
if (other.isSetMyset()) {
  Set __this__myset = new HashSet(other.myset);
  this.myset = __this__myset;
}   
  }
{code}

VS

{code:title=Test2.java -- shallow..?|borderStyle=solid}
  /**
   * Performs a deep copy on other.
   */
  public Test2(Test2 other) {
if (other.isSetMyset()) {
  this.myset = other.myset;
}
  }
{code}

  was:
Consider the following structures:

{code:title=thrift|borderStyle=solid}
typedef set sset;

struct Test {
  1: set myset;
}

struct Test2 {
  1: sset myset;
}
{code}

The generated code for Test's copy constructor looks fine, it deep copies the 
set. However, Test2, which should be equivalent, actually does not deep-copy 
the set and instead simply does a shallow assignment like if it was a POD type. 

{code:title=Test.java|borderStyle=solid}
  /** 
   * Performs a deep copy on other.
   */
  public Test(Test other) {
if (other.isSetMyset()) {
  Set __this__myset = new HashSet(other.myset);
  this.myset = __this__myset;
}   
  }
{code}

VS

{code:title=Test2.java|borderStyle=solid}
  /**
   * Performs a deep copy on other.
   */
  public Test2(Test2 other) {
if (other.isSetMyset()) {
  this.myset = other.myset; // Not deep...
}
  }
{code}


> Deep copy is actually shallow when using typedef members
> 
>
> Key: THRIFT-3377
> URL: https://issues.apache.org/jira/browse/THRIFT-3377
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.9.2
>Reporter: Vincent Dumont
>
> Consider the following structures:
> {code:title=thrift|borderStyle=solid}
> typedef set sset;
> struct Test {
>   1: set myset;
> }
> struct Test2 {
>   1: sset myset;
> }
> {code}
> The generated code for Test's copy constructor looks fine, it deep copies the 
> set. However, Test2, which should be equivalent, actually does not deep-copy 
> the set and instead simply does a shallow assignment like if it was a POD 
> type. 
> {code:title=Test.java -- deep|borderStyle=solid}
>   /** 
>* Performs a deep copy on other.
>*/
>   public Test(Test other) {
> if (other.isSetMyset()) {
>   Set __this__myset = new HashSet(other.myset);
>   this.myset = __this__myset;
> }   
>   }
> {code}
> VS
> {code:title=Test2.java -- shallow..?|borderStyle=solid}
>   /**
>* Performs a deep copy on other.
>*/
>   public Test2(Test2 other) {
> if (other.isSetMyset()) {
>   this.myset = other.myset;
> }
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3378) c_glib service does not handle negative Thrift byte values correctly

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3378:


GitHub user nsuke opened a pull request:

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

THRIFT-3378 c_glib service does not handle negative Thrift byte value…

…s correctly

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

$ git pull https://github.com/nsuke/thrift THRIFT-3378

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

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


commit 2ffb9e69f3049709dbb6eeb077b60ff36adda138
Author: Nobuaki Sukegawa 
Date:   2015-10-10T01:45:42Z

THRIFT-3378 c_glib service does not handle negative Thrift byte values 
correctly




> c_glib service does not handle negative Thrift byte values correctly
> 
>
> Key: THRIFT-3378
> URL: https://issues.apache.org/jira/browse/THRIFT-3378
> Project: Thrift
>  Issue Type: Bug
>  Components: C glib - Compiler
>Reporter: Nobuaki Sukegawa
>
> There's a problematic type cast in generated c_glib service code that treat 
> the sign bit of gint8 as normal bit (i.e. 128).
> The problem is illustrated as follows.
> {code}
> int i = 0;
> users_handler_func((*gint8));  // Suppose this function tries to set i to 
> -100
> store_handler_result(i); // This stores 156, not -100
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift pull request: THRIFT-3276 Binary data does not decode corre...

[nsuke]

GitHub user nsuke opened a pull request:

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

THRIFT-3276 Binary data does not decode correctly using the TJSONProt…

…ocol when the base64 encoded data is padded.

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

$ git pull https://github.com/nsuke/thrift THRIFT-3276

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

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


commit aa8ec9ef94372ca8035b2c90d7efa07ddf326880
Author: Nobuaki Sukegawa 
Date:   2015-10-10T01:44:07Z

THRIFT-3276 Binary data does not decode correctly using the TJSONProtocol 
when the base64 encoded data is padded.




---
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: THRIFT-3378 c_glib service does not handle ne...

[nsuke]

GitHub user nsuke opened a pull request:

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

THRIFT-3378 c_glib service does not handle negative Thrift byte value…

…s correctly

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

$ git pull https://github.com/nsuke/thrift THRIFT-3378

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

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


commit 2ffb9e69f3049709dbb6eeb077b60ff36adda138
Author: Nobuaki Sukegawa 
Date:   2015-10-10T01:45:42Z

THRIFT-3378 c_glib service does not handle negative Thrift byte values 
correctly




---
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] [Updated] (THRIFT-3276) Binary data does not decode correctly using the TJSONProtocol when the base64 encoded data is padded.

[Nobuaki Sukegawa (JIRA)]

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

Nobuaki Sukegawa updated THRIFT-3276:
-
Component/s: C++ - Library

> Binary data does not decode correctly using the TJSONProtocol when the base64 
> encoded data is padded.
> -
>
> Key: THRIFT-3276
> URL: https://issues.apache.org/jira/browse/THRIFT-3276
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library, Java - Library
>Affects Versions: 0.9.1
>Reporter: Steve Niemitz
>
> If the base64 encoded JSON string has padding bytes at the end, the resulting 
> binary data returned in the thrift object ends up with extra padding bytes 
> (0xFF) at the end.
> It seems like this is caused by the TJSONProtocol [using the padded 
> length|https://github.com/apache/thrift/blob/0.9.1/lib/java/src/org/apache/thrift/protocol/TJSONProtocol.java#L760]
>  when it tries to decode the last chunk, which results in the '=' being 
> converted into binary data.  The DECODE_TABLE defaults to -1 (0xFF), which is 
> how it gets into the final output.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift pull request: THRIFT-3379 Potential out of range panic in G...

[nsuke]

GitHub user nsuke opened a pull request:

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

THRIFT-3379 Potential out of range panic in Go JSON protocols



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

$ git pull https://github.com/nsuke/thrift THRIFT-3379

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

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


commit 95a84dc5f4c348bd119368ba0440a663fa1c5d75
Author: Nobuaki Sukegawa 
Date:   2015-10-10T02:28:54Z

THRIFT-3379 Potential out of range panic in Go JSON protocols




---
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] [Created] (THRIFT-3379) Potential out of range panic in Go JSON protocols

[Nobuaki Sukegawa (JIRA)]

Nobuaki Sukegawa created THRIFT-3379:


 Summary:  Potential out of range panic in Go JSON protocols
 Key: THRIFT-3379
 URL: https://issues.apache.org/jira/browse/THRIFT-3379
 Project: Thrift
  Issue Type: Bug
  Components: Go - Library
Reporter: Nobuaki Sukegawa


Slice length check is incorrect and in rare occasions it can cause run-time 
panic.

{code}
 } else if len(f) >= 0 && f[0] == JSON_NULL[0] {
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3371) Abstract namespace Unix domain sockets broken in C++

[Ben Craig (JIRA)]

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

Ben Craig commented on THRIFT-3371:
---

+1

> Abstract namespace Unix domain sockets broken in C++
> 
>
> Key: THRIFT-3371
> URL: https://issues.apache.org/jira/browse/THRIFT-3371
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
> Environment: Linux
>Reporter: Pavlo Penenko
>
> According to http://man7.org/linux/man-pages/man7/unix.7.html :
>   The socket's address in this namespace is given by the
>   additional bytes in sun_path that are covered by the specified
>   length of the address structure.  (Null bytes in the name have no
>   special significance.)
> This used to work after the THRIFT-1481 change because the structure was 
> 0-initialized but was probably broken later in 
> 3e50a9a1d01950f356242aaab0cbf5fae778b81c
> I have an abstract namespace unit test and a fix coming up on GitHub.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (THRIFT-3049) As an iOS developer, I want a generator and library that produces Swift code

[Jens Geyer (JIRA)]

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

Jens Geyer updated THRIFT-3049:
---
Component/s: (was: Compiler (General))
 Swift - Compiler

> As an iOS developer, I want a generator and library that produces Swift code
> 
>
> Key: THRIFT-3049
> URL: https://issues.apache.org/jira/browse/THRIFT-3049
> Project: Thrift
>  Issue Type: Epic
>  Components: Swift - Compiler
>Reporter: Juan Moreno
>Assignee: Kevin Wooten
> Fix For: 1.0
>
>
> Swift is slowly replacing the legacy Objective-C. To keep thrift with the 
> times, let's bake it in.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-3049) As an iOS developer, I want a generator and library that produces Swift code

[Jens Geyer (JIRA)]

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

Jens Geyer resolved THRIFT-3049.

   Resolution: Fixed
 Assignee: Kevin Wooten
Fix Version/s: 1.0

Committed as part of THRIFT-2905, so I guess this one is solved. Feel free to 
reopen if anyone misses anything that cannot be tracked by a new ticket.

> As an iOS developer, I want a generator and library that produces Swift code
> 
>
> Key: THRIFT-3049
> URL: https://issues.apache.org/jira/browse/THRIFT-3049
> Project: Thrift
>  Issue Type: Epic
>  Components: Swift - Compiler
>Reporter: Juan Moreno
>Assignee: Kevin Wooten
> Fix For: 1.0
>
>
> Swift is slowly replacing the legacy Objective-C. To keep thrift with the 
> times, let's bake it in.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-2905) Cocoa compiler should have option to produce "modern" Objective-C

[Hudson (JIRA)]

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

Hudson commented on THRIFT-2905:


SUCCESS: Integrated in Thrift #1680 (See 
[https://builds.apache.org/job/Thrift/1680/])
THRIFT-2905 Cocoa compiler should have option to produce "modern" (jensg: rev 
56e5b9b01b5a033306d583cd2aec07a0dda3c9f5)
* lib/cocoa/src/protocol/TMultiplexedProtocol.h
* lib/cocoa/src/transport/TTransportException.m
* lib/cocoa/src/TSharedProcessorFactory.h
* lib/cocoa/src/transport/TSSLSocketTransportError.h
* compiler/cpp/src/generate/t_cocoa_generator.cc
* lib/cocoa/src/TApplicationException.m
* lib/cocoa/src/transport/TSSLSocketClient.m
* lib/cocoa/src/TBaseClient.h
* lib/cocoa/src/protocol/TProtocolFactory.h
* lib/cocoa/src/transport/TSocketClient.h
* lib/cocoa/src/transport/THTTPTransport.h
* Thrift.podspec
* lib/cocoa/src/transport/TNSFileHandleTransport.m
* lib/cocoa/src/TProcessor.h
* lib/cocoa/src/TError.m
* lib/cocoa/src/server/TSocketServer.h
* lib/cocoa/src/TError.h
* lib/cocoa/src/protocol/TMultiplexedProtocol.m
* lib/cocoa/src/transport/TMemoryBuffer.m
* lib/cocoa/src/protocol/TCompactProtocol.h
* lib/cocoa/src/transport/TAsyncTransport.h
* lib/cocoa/src/protocol/TProtocol.h
* lib/cocoa/src/transport/TSocketTransport.m
* lib/cocoa/src/TList.swift
* compiler/cpp/compiler.vcxproj
* lib/cocoa/src/transport/TSSLSocketException.m
* lib/cocoa/src/TProtocol.swift
* lib/cocoa/src/protocol/TProtocolUtil.h
* lib/cocoa/src/TSharedProcessorFactory.m
* lib/cocoa/src/server/TSocketServer.m
* lib/cocoa/src/protocol/TProtocolDecorator.m
* lib/cocoa/src/transport/TTransportException.h
* lib/cocoa/src/transport/TSSLSocketTransport.h
* lib/cocoa/src/transport/THTTPClient.m
* compiler/cpp/compiler.vcxproj.filters
* lib/cocoa/src/protocol/TBinaryProtocol.h
* lib/cocoa/src/transport/TFramedTransport.m
* lib/cocoa/src/protocol/TProtocolException.m
* lib/cocoa/src/transport/TSocketTransport.h
* lib/cocoa/src/transport/THTTPSessionTransport.h
* lib/cocoa/src/TApplicationError.h
* lib/cocoa/src/transport/THTTPSessionTransport.m
* lib/cocoa/src/transport/TTransportError.m
* lib/cocoa/src/transport/TTransport.h
* lib/cocoa/src/protocol/TProtocolError.m
* lib/cocoa/src/TException.m
* lib/cocoa/src/TProcessorFactory.h
* lib/cocoa/src/TBaseClient.m
* lib/cocoa/src/transport/TFramedTransport.h
* lib/cocoa/src/TStruct.swift
* compiler/cpp/src/generate/t_swift_generator.cc
* lib/cocoa/src/protocol/TBase.h
* lib/cocoa/src/transport/TSSLSocketTransportError.m
* lib/cocoa/src/TException.h
* lib/cocoa/src/protocol/TProtocolError.h
* lib/cocoa/src/TApplicationError.m
* lib/cocoa/src/transport/THTTPClient.h
* lib/cocoa/src/transport/TSSLSocketTransport.m
* lib/cocoa/src/protocol/TCompactProtocol.m
* compiler/cpp/CMakeLists.txt
* lib/cocoa/src/protocol/TProtocolUtil.m
* lib/cocoa/src/transport/TNSStreamTransport.m
* lib/cocoa/src/transport/TNSStreamTransport.h
* lib/cocoa/src/TObjective-C.h
* lib/cocoa/src/TApplicationException.h
* lib/cocoa/src/TEnum.swift
* lib/cocoa/src/TMap.swift
* lib/cocoa/src/TBinary.swift
* lib/cocoa/src/transport/TNSFileHandleTransport.h
* compiler/cpp/Makefile.am
* lib/cocoa/src/protocol/TBinaryProtocol.m
* lib/cocoa/src/protocol/TProtocolDecorator.h
* lib/cocoa/src/transport/TSSLSocketClient.h
* lib/cocoa/src/transport/TTransportError.h
* lib/cocoa/src/protocol/TProtocolException.h
* lib/cocoa/src/transport/THTTPTransport.m
* lib/cocoa/src/transport/TSocketClient.m
* lib/cocoa/src/transport/TSSLSocketException.h
* lib/cocoa/src/TSerializable.swift
* lib/cocoa/src/transport/TMemoryBuffer.h
* lib/cocoa/src/TSet.swift


> Cocoa compiler should have option to produce "modern" Objective-C
> -
>
> Key: THRIFT-2905
> URL: https://issues.apache.org/jira/browse/THRIFT-2905
> Project: Thrift
>  Issue Type: Improvement
>  Components: Cocoa - Compiler, Swift - Compiler
>Reporter: Jim Speth
>Assignee: Kevin Wooten
>Priority: Minor
> Fix For: 1.0
>
>
> For those that don't need backwards compatibility with older compilers and OS 
> versions, there should be a "modern" option that produces modern Objective-C 
> as described in 
> https://developer.apple.com/library/ios/releasenotes/ObjectiveC/ModernizationObjC/AdoptingModernObjective-C/AdoptingModernObjective-C.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3373) Various fixes for cross test servers and clients

[Hudson (JIRA)]

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

Hudson commented on THRIFT-3373:


SUCCESS: Integrated in Thrift #1680 (See 
[https://builds.apache.org/job/Thrift/1680/])
THRIFT-3373: cross test cleanup Client: build, node, c_glib, cpp, hs, (ra: rev 
983bf7de419dca19dac755970218a7d09bea8553)
* Makefile.am
* configure.ac
* test/rb/integration/TestClient.rb
* test/known_failures_Linux.json
* test/hs/Makefile.am
* test/cpp/Makefile.am
* test/py/TestServer.py
* test/c_glib/Makefile.am
* test/py/Makefile.am
* lib/nodejs/test/test-cases.js
* test/c_glib/src/thrift_test_handler.h
* lib/nodejs/test/client.js
* test/c_glib/src/thrift_test_handler.c
* lib/nodejs/test/test_handler.js
* lib/nodejs/test/test_driver.js


> Various fixes for cross test servers and clients
> 
>
> Key: THRIFT-3373
> URL: https://issues.apache.org/jira/browse/THRIFT-3373
> Project: Thrift
>  Issue Type: Bug
>  Components: Test Suite
>Reporter: Nobuaki Sukegawa
>Assignee: Randy Abernethy
> Fix For: 0.9.4
>
>
> I hope it's the last time such a broad fix is needed on this. 
> * fix testBinary and testMultiException handler of c_glib server
> * nodejs server testBinary handler was missing
> * python and haskell lib names were incorrect in configure.ac (sorry about 
> that)
> * Enable dart in make cross
> * ruby clients did not disconnect from the server
>   Since many test servers use rudimentary TSimpleServer, it resulted in dead 
> locks
> * nodejs clients only half-closed (no more send) the connection.
>the same reason as the above, it resulted in hang.
>   (The patch simply makes it exit with 0 in the end.)
> * python server did not log anything to files
> * nodejs client assumed that map and set orders were preserved



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (THRIFT-3373) Various fixes for cross test servers and clients

[Nobuaki Sukegawa (JIRA)]

Nobuaki Sukegawa created THRIFT-3373:


 Summary: Various fixes for cross test servers and clients
 Key: THRIFT-3373
 URL: https://issues.apache.org/jira/browse/THRIFT-3373
 Project: Thrift
  Issue Type: Bug
  Components: Test Suite
Reporter: Nobuaki Sukegawa


I hope it's the last time such a broad fix is needed on this. 

* fix testBinary and testMultiException handler of c_glib server
* nodejs server testBinary handler was missing
* python and haskell lib names were incorrect in configure.ac (sorry about that)
* Enable dart in make cross
* ruby clients did not disconnect from the server
  Since many test servers use rudimentary TSimpleServer, it resulted in dead 
locks
* nodejs clients only half-closed (no more send) the connection.
   the same reason as the above, it resulted in hang.
  (The patch simply makes it exit with 0 in the end.)
* python server did not log anything to files
* nodejs client assumed that map and set orders were preserved



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3237) Fix TNamedPipeServer::createNamedPipe memory leak

[James E. King, III (JIRA)]

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

James E. King, III commented on THRIFT-3237:


Can someone merge this please?

> Fix TNamedPipeServer::createNamedPipe memory leak
> -
>
> Key: THRIFT-3237
> URL: https://issues.apache.org/jira/browse/THRIFT-3237
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.2
> Environment: Windows
>Reporter: Paweł Janicki
>Assignee: James E. King, III
> Attachments: 
> 0001-THRIFT-3237.-cpp-Fix-TNamedPipeServer-createNamedPip.patch
>
>
> Some resources are not released



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift pull request: THRIFT-3230: transform typedef when getting t...

[lifei]

Github user lifei closed the pull request at:

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


---
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: THRIFT-3230: transform typedef when getting t...

[lifei]

Github user lifei commented on the pull request:

https://github.com/apache/thrift/pull/545#issuecomment-146838596
  

https://github.com/apache/thrift/commit/01a77ab01e7459d96059a2b49d9885d14a360ef1


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

Re: Major feature suggestion/observation

[Roger Meier]

You can use json or xsd output of the Apache Thrift compiler if you need this.

cheers
roger

Quoting David Bennett :


As a very achievable alternative...

How about a simple switch on the current compiler to output the  
parsed data model as an XML or JSON file? Checks like reserved words  
should be suppressed, but otherwise it's just another really simple  
generator.


The point about XML is that it's easily loaded as a DOM or  
manipulated by XSL. You can then write a code generator for a new  
language as an entirely separate standalone project, without needing  
to hack the C++ every time. XSL experts can do their thing, or there  
is probably a StringTemplate driver out there already that can load  
an XML data model and read a template from standard input.


Yes I know it's another step in the toolchain, but we're getting  
used to that for the benefits it can bring.


Regards
David M Bennett FACS


-Original Message-
From: BCG [mailto:bgo...@hushmail.com]
Sent: Thursday, 8 October 2015 1:55 PM
To: dev@thrift.apache.org
Subject: Re: Major feature suggestion/observation

Perhaps an approach that wouldn't require completely rearchitecting  
the compiler could be implement a mechanism that allows filtering  
the generated code as it is being written out. For example, the  
compiler could make a call to some sort of filtering callback that  
has the capability of modifying the "default" code that is  
generated, or even replacing it entirely. Information about the  
current state of the parsing could(should?) also be passed into the  
callback.  If you want a somewhat cheeky eat-your-own-dogfood  
approach, this could even be defined in IDL as a Thrift service,  
with an optional command line flag to the compiler for specifying a  
protocol and transport to an implementation (in that case, people  
could tweak the code generation using their language of choice, or  
even just consume the events to feed into their own completely  
separate template engine if they choose to do so).


I'm sure that a templating tool could be a great approach with  
definite advantages but the Thrift compiler seems pretty baked at  
this point and ripping it apart to rebuild it seems like a  
monumental effort and a huge risk.


I've been using Thrift for a while now and I'm interested in  
contributing to the project.  If this is an area that you all think  
would be valuable to work on, I'd be willing to try to help out  
however I can.  Or if there is another area of the project that has  
a more urgent need of attention, I'd be glad to try to help out  
there instead, just let me know.  Mostly I know Java, C, PHP and  
Javascript and a few other tricks I've learned over the years.


-- Ben

On 10/07/2015 09:12 PM, David Bennett wrote:

[Sorry -- I only just subscribed so missed any earlier commonents on
the dev list]

Your experience parallels mine, except that I'm a compiler guy so  
I've leant more towards language-based solutions, and I've written  
a couple of template engines.


Re simple stuff: agreed. Simple stuff is simple.
Re performance: not interested. There are situations where the  
speed of code generation matters, and this is not one of them.
Re features of the template language: absolutely. A language that  
is not 'Turing Complete' (whatever that means in this context) will  
run into problems it cannot solve.


FWIW TC means state, iteration and alternation, which covers your  
loops and filters. The only way to get there is to include a  
full-blown macro processing language or equivalent (I've written  
one of those too). Look at Tex, m4 for examples. Good page here  
too: https://en.wikipedia.org/wiki/Template_processor. The key  
thing is Model View separation: the C++ parse provides the data  
model and the template language generates the source code View.  
With this separation and a suitable data model, there should  
(almost) never be a need to change anything except individual  
templates.


In practice what I have done is to write special purpose functions  
in the host language and call them from the template. Your keyword  
example would require a language-specific callable function for  
each supported language to check and perhaps mangle identifiers.


But this project is only reasonable if the templating tool exists,  
and it is sufficiently powerful that the conversion is largely  
mechanical, and there are sufficient regression tests to check the  
results.


Of all the tools I know, this one  
https://theantlrguy.atlassian.net/wiki/display/ST4/StringTemplate+4+Documentation is the one that is most likely to be  
suitable.


Regards
David M Bennett FACS

Andl - A New Database Language - andl.org


-Original Message-
From: Jens Geyer [mailto:jensge...@hotmail.com]
Sent: Thursday, 8 October 2015 6:30 AM
To: Thrift-Dev 
Cc: u...@thrift.apache.org
Subject: Re: Major feature suggestion/observation

Hi *,

Please, FUP @ dev list. 

[jira] [Commented] (THRIFT-3230) Python compiler generates wrong code if there is function throwing a typedef of exception with another namespace

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3230:


Github user lifei closed the pull request at:

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


> Python compiler generates wrong code if there is function throwing a typedef 
> of exception with another namespace
> 
>
> Key: THRIFT-3230
> URL: https://issues.apache.org/jira/browse/THRIFT-3230
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Compiler
>Affects Versions: 0.9.2
>Reporter: 李飛
>Assignee: 李飛
>Priority: Blocker
> Fix For: 0.9.3
>
>
> for example:
> {code:title=error.thrift}
> namespace py error
> exception KolodaException {
> string message
> }
> {code}
> {code:title=biz.thrift}
> namespace py biz
> include "error.thrift"
> typedef error.KolodaException KolodaException
> BizService {
> void doSomeBiz() throws (1: KolodaException ex)
> }
> {code}
> compiled code
> {code}
> try:
>   result.success = self._handler.doSomeBiz()
> except KolodaException as ex:
>   result.ex = ex
> {code}
> `except KolodaException as ex:` should be `except error.KolodaException as 
> ex:`



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3230) Python compiler generates wrong code if there is function throwing a typedef of exception with another namespace

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3230:


Github user lifei commented on the pull request:

https://github.com/apache/thrift/pull/545#issuecomment-146838596
  

https://github.com/apache/thrift/commit/01a77ab01e7459d96059a2b49d9885d14a360ef1


> Python compiler generates wrong code if there is function throwing a typedef 
> of exception with another namespace
> 
>
> Key: THRIFT-3230
> URL: https://issues.apache.org/jira/browse/THRIFT-3230
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Compiler
>Affects Versions: 0.9.2
>Reporter: 李飛
>Assignee: 李飛
>Priority: Blocker
> Fix For: 0.9.3
>
>
> for example:
> {code:title=error.thrift}
> namespace py error
> exception KolodaException {
> string message
> }
> {code}
> {code:title=biz.thrift}
> namespace py biz
> include "error.thrift"
> typedef error.KolodaException KolodaException
> BizService {
> void doSomeBiz() throws (1: KolodaException ex)
> }
> {code}
> compiled code
> {code}
> try:
>   result.success = self._handler.doSomeBiz()
> except KolodaException as ex:
>   result.ex = ex
> {code}
> `except KolodaException as ex:` should be `except error.KolodaException as 
> ex:`



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift pull request: Thrift 2905 & - Modern Objective-C & Swift Su...

[Jens-G]

Github user Jens-G commented on the pull request:

https://github.com/apache/thrift/pull/539#issuecomment-146937977
  
>  Maybe we should look at standardizing these codes in general?

Good idea :-) In fact, the exception codes are already standardized for all 
standard Thrift exceptions (`TTransport/Protocol/ApplicationException`). If you 
compare with other languages you'll find they all match.


---
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] [Updated] (THRIFT-3374) Ruby TJSONProtocol fails to unescape string values

[Nobuaki Sukegawa (JIRA)]

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

Nobuaki Sukegawa updated THRIFT-3374:
-
Component/s: Ruby - Library

> Ruby TJSONProtocol fails to unescape string values
> --
>
> Key: THRIFT-3374
> URL: https://issues.apache.org/jira/browse/THRIFT-3374
> Project: Thrift
>  Issue Type: Bug
>  Components: Ruby - Library
>Reporter: Nobuaki Sukegawa
>
> It does try to unescape characters but fails to do so because it uses single 
> quotes for unescape results:
> {code}
> '"', '\\', '/', '\b', '\f', '\n', '\r', '\t',
> {code}
> End result was the exactly same unescaped characters as input text.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (THRIFT-3375) Python TJSONProtocol encodes utf8 string values in an incompatible way

[Nobuaki Sukegawa (JIRA)]

Nobuaki Sukegawa created THRIFT-3375:


 Summary: Python TJSONProtocol encodes utf8 string values in an 
incompatible way
 Key: THRIFT-3375
 URL: https://issues.apache.org/jira/browse/THRIFT-3375
 Project: Thrift
  Issue Type: Bug
  Components: Python - Library
Reporter: Nobuaki Sukegawa


It uses *json.dump* method with *ensure_ascii=True* (via default arg) that 
escapes utf8 characters.
And yet, many implementations including Python does not attempt to unescape 
those characters so cannot talk to each other nor to itself, if the value has 
any utf8 character.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift pull request: THRIFT-3375 Python TJSONProtocol encodes utf8...

[nsuke]

GitHub user nsuke opened a pull request:

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

THRIFT-3375 Python TJSONProtocol encodes utf8 string values in an inc…

…ompatible way

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

$ git pull https://github.com/nsuke/thrift THRIFT-3375

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

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


commit 9a6bfbb33887b57d0184a8343fd7732d39e6a165
Author: Nobuaki Sukegawa 
Date:   2015-10-09T17:12:48Z

THRIFT-3375 Python TJSONProtocol encodes utf8 string values in an 
incompatible way




---
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] [Created] (THRIFT-3374) Ruby TJSONProtocol fails to unescape string values

[Nobuaki Sukegawa (JIRA)]

Nobuaki Sukegawa created THRIFT-3374:


 Summary: Ruby TJSONProtocol fails to unescape string values
 Key: THRIFT-3374
 URL: https://issues.apache.org/jira/browse/THRIFT-3374
 Project: Thrift
  Issue Type: Bug
Reporter: Nobuaki Sukegawa


It does try to unescape characters but fails to do so because it uses single 
quotes for unescape results:

{code}
'"', '\\', '/', '\b', '\f', '\n', '\r', '\t',
{code}

End result was the exactly same unescaped characters as input text.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift pull request: THRIFT-3374 Ruby TJSONProtocol fails to unesc...

[nsuke]

GitHub user nsuke opened a pull request:

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

THRIFT-3374 Ruby TJSONProtocol fails to unescape string values



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

$ git pull https://github.com/nsuke/thrift THRIFT-3374

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

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


commit 636b089e8b5de57d4388afa2198a02fd43d0ed15
Author: Nobuaki Sukegawa 
Date:   2015-10-09T16:52:13Z

THRIFT-3374 Ruby TJSONProtocol fails to unescape string values




---
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-3374) Ruby TJSONProtocol fails to unescape string values

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3374:


GitHub user nsuke opened a pull request:

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

THRIFT-3374 Ruby TJSONProtocol fails to unescape string values



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

$ git pull https://github.com/nsuke/thrift THRIFT-3374

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

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


commit 636b089e8b5de57d4388afa2198a02fd43d0ed15
Author: Nobuaki Sukegawa 
Date:   2015-10-09T16:52:13Z

THRIFT-3374 Ruby TJSONProtocol fails to unescape string values




> Ruby TJSONProtocol fails to unescape string values
> --
>
> Key: THRIFT-3374
> URL: https://issues.apache.org/jira/browse/THRIFT-3374
> Project: Thrift
>  Issue Type: Bug
>Reporter: Nobuaki Sukegawa
>
> It does try to unescape characters but fails to do so because it uses single 
> quotes for unescape results:
> {code}
> '"', '\\', '/', '\b', '\f', '\n', '\r', '\t',
> {code}
> End result was the exactly same unescaped characters as input text.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift pull request: THRIFT-3373 Various fixes for cross test serv...

[nsuke]

GitHub user nsuke opened a pull request:

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

THRIFT-3373 Various fixes for cross test servers and clients



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

$ git pull https://github.com/nsuke/thrift THRIFT-3373

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

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


commit 338f1a502961a4f63b0bd4b3dae4099062d6d17f
Author: Nobuaki Sukegawa 
Date:   2015-10-09T17:25:18Z

THRIFT-3373 Various fixes for cross test servers and clients




---
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-3373) Various fixes for cross test servers and clients

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3373:


GitHub user nsuke opened a pull request:

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

THRIFT-3373 Various fixes for cross test servers and clients



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

$ git pull https://github.com/nsuke/thrift THRIFT-3373

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

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


commit 338f1a502961a4f63b0bd4b3dae4099062d6d17f
Author: Nobuaki Sukegawa 
Date:   2015-10-09T17:25:18Z

THRIFT-3373 Various fixes for cross test servers and clients




> Various fixes for cross test servers and clients
> 
>
> Key: THRIFT-3373
> URL: https://issues.apache.org/jira/browse/THRIFT-3373
> Project: Thrift
>  Issue Type: Bug
>  Components: Test Suite
>Reporter: Nobuaki Sukegawa
>
> I hope it's the last time such a broad fix is needed on this. 
> * fix testBinary and testMultiException handler of c_glib server
> * nodejs server testBinary handler was missing
> * python and haskell lib names were incorrect in configure.ac (sorry about 
> that)
> * Enable dart in make cross
> * ruby clients did not disconnect from the server
>   Since many test servers use rudimentary TSimpleServer, it resulted in dead 
> locks
> * nodejs clients only half-closed (no more send) the connection.
>the same reason as the above, it resulted in hang.
>   (The patch simply makes it exit with 0 in the end.)
> * python server did not log anything to files
> * nodejs client assumed that map and set orders were preserved



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3375) Python TJSONProtocol encodes utf8 string values in an incompatible way

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3375:


GitHub user nsuke opened a pull request:

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

THRIFT-3375 Python TJSONProtocol encodes utf8 string values in an inc…

…ompatible way

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

$ git pull https://github.com/nsuke/thrift THRIFT-3375

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

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


commit 9a6bfbb33887b57d0184a8343fd7732d39e6a165
Author: Nobuaki Sukegawa 
Date:   2015-10-09T17:12:48Z

THRIFT-3375 Python TJSONProtocol encodes utf8 string values in an 
incompatible way




> Python TJSONProtocol encodes utf8 string values in an incompatible way
> --
>
> Key: THRIFT-3375
> URL: https://issues.apache.org/jira/browse/THRIFT-3375
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Reporter: Nobuaki Sukegawa
>
> It uses *json.dump* method with *ensure_ascii=True* (via default arg) that 
> escapes utf8 characters.
> And yet, many implementations including Python does not attempt to unescape 
> those characters so cannot talk to each other nor to itself, if the value has 
> any utf8 character.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (THRIFT-3376) C# and Python JSON protocol double values lose precision

[Nobuaki Sukegawa (JIRA)]

Nobuaki Sukegawa created THRIFT-3376:


 Summary: C# and Python JSON protocol double values lose precision
 Key: THRIFT-3376
 URL: https://issues.apache.org/jira/browse/THRIFT-3376
 Project: Thrift
  Issue Type: Bug
  Components: C# - Library, Python - Library
Reporter: Nobuaki Sukegawa


These two use default ToString/str methods that do not fully preserve double 
precision.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift pull request: THRIFT-3376 C# and Python JSON protocol doubl...

[nsuke]

GitHub user nsuke opened a pull request:

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

THRIFT-3376 C# and Python JSON protocol double values lose precision



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

$ git pull https://github.com/nsuke/thrift THRIFT-3376

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

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


commit 09296d1fa6fa6db3f40c8c1c134b41f200b150ab
Author: Nobuaki Sukegawa 
Date:   2015-10-09T18:11:49Z

THRIFT-3376 C# and Python JSON protocol double values lose precision




---
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-3376) C# and Python JSON protocol double values lose precision

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3376:


GitHub user nsuke opened a pull request:

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

THRIFT-3376 C# and Python JSON protocol double values lose precision



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

$ git pull https://github.com/nsuke/thrift THRIFT-3376

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

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


commit 09296d1fa6fa6db3f40c8c1c134b41f200b150ab
Author: Nobuaki Sukegawa 
Date:   2015-10-09T18:11:49Z

THRIFT-3376 C# and Python JSON protocol double values lose precision




> C# and Python JSON protocol double values lose precision
> 
>
> Key: THRIFT-3376
> URL: https://issues.apache.org/jira/browse/THRIFT-3376
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library, Python - Library
>Reporter: Nobuaki Sukegawa
>
> These two use default ToString/str methods that do not fully preserve double 
> precision.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift pull request: Thrift 2905 & - Modern Objective-C & Swift Su...

[kdubb]

Github user kdubb commented on the pull request:

https://github.com/apache/thrift/pull/539#issuecomment-146952528
  
I've brought the exception reporting in line with other languages.  I 
looked into Java & C++ to see the error codes they for all.  Historically 
TApplicationError seems to have been correct in the past and I trampled on it 
by changing the codes themselves.  The protocol & transport errors needed a bit 
of shuffling but now they are using a meaningful code in the correct context.  
I've kept some of the extended error information we were traditionally 
reporting but put it into variables that do not escape the current environment.


---
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] [Assigned] (THRIFT-3373) Various fixes for cross test servers and clients

[Randy Abernethy (JIRA)]

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

Randy Abernethy reassigned THRIFT-3373:
---

Assignee: Randy Abernethy

> Various fixes for cross test servers and clients
> 
>
> Key: THRIFT-3373
> URL: https://issues.apache.org/jira/browse/THRIFT-3373
> Project: Thrift
>  Issue Type: Bug
>  Components: Test Suite
>Reporter: Nobuaki Sukegawa
>Assignee: Randy Abernethy
>
> I hope it's the last time such a broad fix is needed on this. 
> * fix testBinary and testMultiException handler of c_glib server
> * nodejs server testBinary handler was missing
> * python and haskell lib names were incorrect in configure.ac (sorry about 
> that)
> * Enable dart in make cross
> * ruby clients did not disconnect from the server
>   Since many test servers use rudimentary TSimpleServer, it resulted in dead 
> locks
> * nodejs clients only half-closed (no more send) the connection.
>the same reason as the above, it resulted in hang.
>   (The patch simply makes it exit with 0 in the end.)
> * python server did not log anything to files
> * nodejs client assumed that map and set orders were preserved



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift pull request: THRIFT-3373 Various fixes for cross test serv...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-3373) Various fixes for cross test servers and clients

[Randy Abernethy (JIRA)]

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

Randy Abernethy resolved THRIFT-3373.
-
   Resolution: Fixed
Fix Version/s: 0.9.4

committed, thanks for the patch!

> Various fixes for cross test servers and clients
> 
>
> Key: THRIFT-3373
> URL: https://issues.apache.org/jira/browse/THRIFT-3373
> Project: Thrift
>  Issue Type: Bug
>  Components: Test Suite
>Reporter: Nobuaki Sukegawa
>Assignee: Randy Abernethy
> Fix For: 0.9.4
>
>
> I hope it's the last time such a broad fix is needed on this. 
> * fix testBinary and testMultiException handler of c_glib server
> * nodejs server testBinary handler was missing
> * python and haskell lib names were incorrect in configure.ac (sorry about 
> that)
> * Enable dart in make cross
> * ruby clients did not disconnect from the server
>   Since many test servers use rudimentary TSimpleServer, it resulted in dead 
> locks
> * nodejs clients only half-closed (no more send) the connection.
>the same reason as the above, it resulted in hang.
>   (The patch simply makes it exit with 0 in the end.)
> * python server did not log anything to files
> * nodejs client assumed that map and set orders were preserved



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (THRIFT-3373) Various fixes for cross test servers and clients

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-3373:


Github user asfgit closed the pull request at:

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


> Various fixes for cross test servers and clients
> 
>
> Key: THRIFT-3373
> URL: https://issues.apache.org/jira/browse/THRIFT-3373
> Project: Thrift
>  Issue Type: Bug
>  Components: Test Suite
>Reporter: Nobuaki Sukegawa
>Assignee: Randy Abernethy
> Fix For: 0.9.4
>
>
> I hope it's the last time such a broad fix is needed on this. 
> * fix testBinary and testMultiException handler of c_glib server
> * nodejs server testBinary handler was missing
> * python and haskell lib names were incorrect in configure.ac (sorry about 
> that)
> * Enable dart in make cross
> * ruby clients did not disconnect from the server
>   Since many test servers use rudimentary TSimpleServer, it resulted in dead 
> locks
> * nodejs clients only half-closed (no more send) the connection.
>the same reason as the above, it resulted in hang.
>   (The patch simply makes it exit with 0 in the end.)
> * python server did not log anything to files
> * nodejs client assumed that map and set orders were preserved



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (THRIFT-2905) Cocoa compiler should have option to produce "modern" Objective-C

[Jens Geyer (JIRA)]

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

Jens Geyer updated THRIFT-2905:
---
Component/s: Swift - Compiler

> Cocoa compiler should have option to produce "modern" Objective-C
> -
>
> Key: THRIFT-2905
> URL: https://issues.apache.org/jira/browse/THRIFT-2905
> Project: Thrift
>  Issue Type: Improvement
>  Components: Cocoa - Compiler, Swift - Compiler
>Reporter: Jim Speth
>Priority: Minor
>
> For those that don't need backwards compatibility with older compilers and OS 
> versions, there should be a "modern" option that produces modern Objective-C 
> as described in 
> https://developer.apple.com/library/ios/releasenotes/ObjectiveC/ModernizationObjC/AdoptingModernObjective-C/AdoptingModernObjective-C.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift pull request: Thrift 2905 & - Modern Objective-C & Swift Su...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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] [Updated] (THRIFT-2905) Cocoa compiler should have option to produce "modern" Objective-C

[Jens Geyer (JIRA)]

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

Jens Geyer updated THRIFT-2905:
---
Assignee: Kevin Wooten

> Cocoa compiler should have option to produce "modern" Objective-C
> -
>
> Key: THRIFT-2905
> URL: https://issues.apache.org/jira/browse/THRIFT-2905
> Project: Thrift
>  Issue Type: Improvement
>  Components: Cocoa - Compiler, Swift - Compiler
>Reporter: Jim Speth
>Assignee: Kevin Wooten
>Priority: Minor
>
> For those that don't need backwards compatibility with older compilers and OS 
> versions, there should be a "modern" option that produces modern Objective-C 
> as described in 
> https://developer.apple.com/library/ios/releasenotes/ObjectiveC/ModernizationObjC/AdoptingModernObjective-C/AdoptingModernObjective-C.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (THRIFT-2905) Cocoa compiler should have option to produce "modern" Objective-C

[Jens Geyer (JIRA)]

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

Jens Geyer resolved THRIFT-2905.

   Resolution: Fixed
Fix Version/s: 1.0

Committed - thanks for all the work. 

> Cocoa compiler should have option to produce "modern" Objective-C
> -
>
> Key: THRIFT-2905
> URL: https://issues.apache.org/jira/browse/THRIFT-2905
> Project: Thrift
>  Issue Type: Improvement
>  Components: Cocoa - Compiler, Swift - Compiler
>Reporter: Jim Speth
>Assignee: Kevin Wooten
>Priority: Minor
> Fix For: 1.0
>
>
> For those that don't need backwards compatibility with older compilers and OS 
> versions, there should be a "modern" option that produces modern Objective-C 
> as described in 
> https://developer.apple.com/library/ios/releasenotes/ObjectiveC/ModernizationObjC/AdoptingModernObjective-C/AdoptingModernObjective-C.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)