[jira] [Resolved] (THRIFT-3921) C++ code should print enums as strings
[ 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
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
[ 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
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
[ 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
[ 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, IIIDate: 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...
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, IIIDate: 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
[ 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 ...
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. ---