[jira] [Resolved] (THRIFT-3921) C++ code should print enums as strings

2017-02-28 Thread James E. King, III (JIRA)

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

James E. King, III resolved THRIFT-3921.

Resolution: Fixed

> C++ code should print enums as strings
> --
>
> Key: THRIFT-3921
> URL: https://issues.apache.org/jira/browse/THRIFT-3921
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler
>Reporter: Vivek Jain
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> THRIFT-2067 added {{operator<<}} to the C++ generated code, which is great, 
> but enums are printed as numbers rather than their string representation. It 
> would be great if the generated code printed them as a string instead. There 
> might be some backwards-compatibility concerns (if users have already defined 
> their own versions, then thrift's version would cause compile errors), not 
> sure how important you guys think those are.
> Other thoughts/concerns? I am willing to work on a patch if no one else is 
> able to work on it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (THRIFT-4106) concurrency_test fails randomly on MinGW

2017-02-28 Thread James E. King, III (JIRA)
James E. King, III created THRIFT-4106:
--

 Summary: concurrency_test fails randomly on MinGW
 Key: THRIFT-4106
 URL: https://issues.apache.org/jira/browse/THRIFT-4106
 Project: Thrift
  Issue Type: Bug
  Components: C++ - Library
Affects Versions: 0.11.0
 Environment: MinGW (appveyor)
Reporter: James E. King, III
Assignee: James E. King, III


While adding Appveyor build support for MinGW (THRIFT-4081), this test failed 
periodically.  It would throw an exception in ThreadFactoryTest reapTest where 
it calls monitor.wait(1000).  It is reproducible locally as well if you have 
msys2/mingw64 and can use the instructions in the msys2 readme in build/cmake.  
The test has been disabled in mingw appveyor builds for now (those builds are 
new...)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (THRIFT-2850) Have the cmake build system run make cross

2017-02-28 Thread James E. King, III (JIRA)

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

James E. King, III updated THRIFT-2850:
---
Summary: Have the cmake build system run make cross  (was: As a developer, 
I want the cmake build system to run make cross)

> Have the cmake build system run make cross
> --
>
> Key: THRIFT-2850
> URL: https://issues.apache.org/jira/browse/THRIFT-2850
> Project: Thrift
>  Issue Type: Improvement
>  Components: Build Process
> Environment: all platforms
>Reporter: Roger Meier
>Assignee: Roger Meier
>  Labels: appveyor, cmake, travis
> Fix For: 1.0
>
> Attachments: 0001-THRIFT-2850-CMake-for-Apache-Thrift.patch, 
> THRIFT-2850_change_name_add_test_py.patch
>
>
> Goal: Extend Apache Thrift's *make cross* approach to the build system.
> Due to growing the field of operating system support, a proper executable
> and library detection mechanism running on as much platforms as possible
> becomes required. The other aspect is simplify the release process and
> package generation process.
> As nice side benefit of CMake is the generation of development environment
> specific solution files(VisualStudio, Eclipse, Xcode, etc. ). => No solution 
> files within source tree.
> We are already building Apache Thrift with CMake for Linux-ARM, Linux-x86, 
> Windows CE and Windows.
> We are in preparation phase for a pull request here:
> https://github.com/siemens/thrift/commits/cmake-master



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] thrift issue #1084: THRIFT-3773 Swift 3 Native Library

2017-02-28 Thread apocolipse
Github user apocolipse commented on the issue:

https://github.com/apache/thrift/pull/1084
  
Update 2/28/2017:
Old Swift generator and new merged into one,
Old generator under `cocoa` option, `promise_kit` option only available for 
old generator as well.

I don't have any Swift 2.x projects so i can't really test, but if anyone 
else wants to spot check code and test against old versions that'd be great.  
I've left the old swift generator CC file in tact (moved to `*.cc..old`), and 
spaced out things such that it lines up with the new code line for line for 
comparison.

Next and last steps to make this production ready IMO is namespacing, I'm 
going to add an option to namespace by splitting into subdirectories.  Actually 
configuring projects will be left up to the developer.  I'll add some output 
describing how to do it in SPM, but injecting the targets into SPM or Xcodeproj 
are beyond the scope of Thrift so for now the only thing namespacing will do is 
place source files in their own namespace relative directory, generate imports 
when necessary, and appropriately namespace types.  Any suggestions or input 
are welcome.


---
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-3773) Swift Library

2017-02-28 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-3773:


Github user apocolipse commented on the issue:

https://github.com/apache/thrift/pull/1084
  
Update 2/28/2017:
Old Swift generator and new merged into one,
Old generator under `cocoa` option, `promise_kit` option only available for 
old generator as well.

I don't have any Swift 2.x projects so i can't really test, but if anyone 
else wants to spot check code and test against old versions that'd be great.  
I've left the old swift generator CC file in tact (moved to `*.cc..old`), and 
spaced out things such that it lines up with the new code line for line for 
comparison.

Next and last steps to make this production ready IMO is namespacing, I'm 
going to add an option to namespace by splitting into subdirectories.  Actually 
configuring projects will be left up to the developer.  I'll add some output 
describing how to do it in SPM, but injecting the targets into SPM or Xcodeproj 
are beyond the scope of Thrift so for now the only thing namespacing will do is 
place source files in their own namespace relative directory, generate imports 
when necessary, and appropriately namespace types.  Any suggestions or input 
are welcome.


> Swift Library
> -
>
> Key: THRIFT-3773
> URL: https://issues.apache.org/jira/browse/THRIFT-3773
> Project: Thrift
>  Issue Type: New Feature
>  Components: Swift - Library
>Reporter: Thomas Bartelmess
>Assignee: Chris Simpson
>
> We already have the option to generate Swift code in the Cocoa compiler, 
> however large parts of the (Objective-C) Cocoa Library still depend on Cocoa 
> and  Objective-C.
> It would be good to have a native Swift library that doesn't depend on the 
> Cocoa libraries.
> Design goals:
> - Fully compatible with the code that is currently generated by the Cocoa 
> compiler (both Objective-C and Swift).
> - Ability to run on Linux
> - Pure Swift, no Objective-C code.
> - No dependencies on closed source apple libraries
> - Keep the same interface, so that the library is compatible with the code 
> the current cocoa compiler generates
> - Better server support that the current Objective-C library.
> - Follow the new Swift packaging format to be compatible with the Swift 
> Package manager



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (THRIFT-4081) Provide a MinGW 64-bit Appveyor CI build for better pull request validation

2017-02-28 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-4081:


GitHub user jeking3 opened a pull request:

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

THRIFT-4081: appveyor retooling - build both MSVC2015 and MINGW on appveyor

Also enabled Qt 5.8 for the MSVC build and cleaned up a bunch of smaller 
things the MINGW build found.

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

$ git pull https://github.com/jeking3/thrift THRIFT-4081-appveyor

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

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


commit 63c4a0fdfd75c297d447e31cfeead9187507c034
Author: James E. King, III 
Date:   2017-02-22T20:54:26Z

THRIFT-4081: appveyor retooling - working on msys2/mingw64 as msvc 2010 and 
2015 are close to working




> Provide a MinGW 64-bit Appveyor CI build for better pull request validation
> ---
>
> Key: THRIFT-4081
> URL: https://issues.apache.org/jira/browse/THRIFT-4081
> Project: Thrift
>  Issue Type: Improvement
>  Components: Build Process
>Affects Versions: 0.10.0
> Environment: Appveyor
>Reporter: James E. King, III
>Assignee: James E. King, III
>
> We currently build in Visual Studio 2015 on Appveyor.  We do not use the 
> Windows CI environment to verify that MinGW still builds successfully (there 
> is a 32-bit job on linux, #16, which runs on every pull request).  I would 
> recommend that we add a CI build job to Appveyor and/or extend the existing 
> job to build with the latest MinGW 64-bit environment which includes 
> gcc-6.3.0; we could perhaps remove Travis job #16 which is using 32-bit mingw 
> on linux as a result?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] thrift pull request #1205: THRIFT-4081: appveyor retooling - build both MSVC...

2017-02-28 Thread jeking3
GitHub user jeking3 opened a pull request:

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

THRIFT-4081: appveyor retooling - build both MSVC2015 and MINGW on appveyor

Also enabled Qt 5.8 for the MSVC build and cleaned up a bunch of smaller 
things the MINGW build found.

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

$ git pull https://github.com/jeking3/thrift THRIFT-4081-appveyor

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

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


commit 63c4a0fdfd75c297d447e31cfeead9187507c034
Author: James E. King, III 
Date:   2017-02-22T20:54:26Z

THRIFT-4081: appveyor retooling - working on msys2/mingw64 as msvc 2010 and 
2015 are close to working




---
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-3921) C++ code should print enums as strings

2017-02-28 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on THRIFT-3921:


Github user asfgit closed the pull request at:

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


> C++ code should print enums as strings
> --
>
> Key: THRIFT-3921
> URL: https://issues.apache.org/jira/browse/THRIFT-3921
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler
>Reporter: Vivek Jain
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> THRIFT-2067 added {{operator<<}} to the C++ generated code, which is great, 
> but enums are printed as numbers rather than their string representation. It 
> would be great if the generated code printed them as a string instead. There 
> might be some backwards-compatibility concerns (if users have already defined 
> their own versions, then thrift's version would cause compile errors), not 
> sure how important you guys think those are.
> Other thoughts/concerns? I am willing to work on a patch if no one else is 
> able to work on it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] thrift pull request #1204: THRIFT-3921: fix ostream definitions so they are ...

2017-02-28 Thread asfgit
Github user asfgit closed the pull request at:

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


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