[jira] [Commented] (THRIFT-4489) Unix domain socket support for NodeJS client
[ https://issues.apache.org/jira/browse/THRIFT-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16404221#comment-16404221 ] ASF GitHub Bot commented on THRIFT-4489: Github user danielhtshih commented on the issue: https://github.com/apache/thrift/pull/1491 I believe the unexpected failures from the latest run is not related to my changes for nodejs. Maybe it needs another merge from master branch? ``` === Following 14 tests were expected to cleanly succeed but needed retry: === server-client: protocol: transport: result: nodejs-nodejs json buffered-domain flaky(1 retry) nodejs-cpp json buffered-ip-ssl flaky(3 retries) hs-csharp json framed-ipflaky(2 retries) cpp-cpp multicframed-ip-sslflaky(2 retries) cpp-cpp multij-json http-ip-ssl flaky(1 retry) cpp-cpp multij-json framed-ip-sslflaky(1 retry) cpp-cpp multihhttp-ip-ssl flaky(1 retry) cpp-cpp multih-header http-ip-ssl flaky(2 retries) cpp-cpp multih-header buffered-ip-ssl flaky(2 retries) cpp-cpp multic-compacthttp-ip-ssl flaky(1 retry) cpp-cpp multic-compactbuffered-ip-ssl flaky(3 retries) cpp-cpp multij-json http-ip-ssl flaky(1 retry) cpp-cpp multij-json buffered-ip-ssl flaky(1 retry) cpp-cpp multijbuffered-ip-ssl flaky(2 retries) === *** Following 1 failures were unexpected ***: If it is introduced by you, please fix it before submitting the code. === server-client: protocol: transport: result: cpp-cpp multij-json buffered-ip-ssl failure(64) === ``` > Unix domain socket support for NodeJS client > > > Key: THRIFT-4489 > URL: https://issues.apache.org/jira/browse/THRIFT-4489 > Project: Thrift > Issue Type: Improvement > Components: Node.js - Library >Affects Versions: 0.11.0 >Reporter: Daniel Shih >Assignee: James E. King, III >Priority: Major > > I would like to use Unix domain sockets for NodeJS client, > Here is the proposed PR: https://github.com/apache/thrift/pull/1491 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] thrift issue #1491: THRIFT-4489: Add UDS support for nodejs thrift client
Github user danielhtshih commented on the issue: https://github.com/apache/thrift/pull/1491 I believe the unexpected failures from the latest run is not related to my changes for nodejs. Maybe it needs another merge from master branch? ``` === Following 14 tests were expected to cleanly succeed but needed retry: === server-client: protocol: transport: result: nodejs-nodejs json buffered-domain flaky(1 retry) nodejs-cpp json buffered-ip-ssl flaky(3 retries) hs-csharp json framed-ipflaky(2 retries) cpp-cpp multicframed-ip-sslflaky(2 retries) cpp-cpp multij-json http-ip-ssl flaky(1 retry) cpp-cpp multij-json framed-ip-sslflaky(1 retry) cpp-cpp multihhttp-ip-ssl flaky(1 retry) cpp-cpp multih-header http-ip-ssl flaky(2 retries) cpp-cpp multih-header buffered-ip-ssl flaky(2 retries) cpp-cpp multic-compacthttp-ip-ssl flaky(1 retry) cpp-cpp multic-compactbuffered-ip-ssl flaky(3 retries) cpp-cpp multij-json http-ip-ssl flaky(1 retry) cpp-cpp multij-json buffered-ip-ssl flaky(1 retry) cpp-cpp multijbuffered-ip-ssl flaky(2 retries) === *** Following 1 failures were unexpected ***: If it is introduced by you, please fix it before submitting the code. === server-client: protocol: transport: result: cpp-cpp multij-json buffered-ip-ssl failure(64) === ``` ---
Re: Problems compiling master dotnet and csharp on ubuntu-xenial docker
Hi, occasionally the "make clean" rules seem to run out of sync (probably because nobody tests that). I run into similar things a few times myself. If it happens that find the guilty, please fix it. Thanks + have fun, JensG -Ursprüngliche Nachricht- From: Allen George Sent: Friday, March 16, 2018 3:02 AM To: dev@thrift.apache.org Subject: Re: Problems compiling master dotnet and csharp on ubuntu-xenial docker I tried “make clean” and the problem persisted. I then went into the tutorial directory and deleted the “obj” and “bin” folders - problem solved. There must be some missing rule somewhere; either that, or I’d garbage left over from an older build. Thank you for pointing me in the right direction - I’ll keep that in mind in the future. Best, Allen On March 15, 2018 at 20:00:09, Jens Geyer (jensge...@hotmail.com) wrote: Maybe a dumb question, but... are there some duplicate files in the way? Did you try using a fresh working copy? -Ursprüngliche Nachricht- From: Allen George Sent: Wednesday, March 14, 2018 11:05 PM To: dev@thrift.apache.org Subject: Re: Problems compiling master dotnet and csharp on ubuntu-xenial docker Hi JensG and Jim, You’re absolutely right - my initial message wasn't useful; I typed before I thought. Using the ubuntu-xenial docker container. master as of today morning Ran "./bootstrap.sh" followed by “./configure” followed by “make -j2 precross” and then "make precross" I get a large number of errors from dotnetcore that I’ve saved in this gist: https://gist.github.com/allengeorge/4dcd99ed9851513714669e277a505950 A sampling: Thrift -> /thrift/src/lib/netcore/Thrift/bin/Debug/netstandard2.0/Thrift.dll tutorial/tutorial.Constants.cs(22,23): error CS0101: The namespace 'tutorial' already contains a definition for 'tutorialConstants' [/thrift/src/tutorial/netcore/Interfaces/Interfaces.csproj] tutorial/Operation.cs(14,15): error CS0101: The namespace 'tutorial' already contains a definition for 'Operation' [/thrift/src/tutorial/netcore/Interfaces/Interfaces.csproj] shared/SharedStruct.cs(68,19): error CS0102: The type 'SharedStruct' already contains a definition for 'Isset' [/thrift/src/tutorial/netcore/Interfaces/Interfaces.csproj] … I’ll also run about with “make precross” only. Any help would be appreciated. TY! Allen On March 14, 2018 at 15:18:40, Jens Geyer (jensge...@hotmail.com) wrote: Hi, I just want to emphasize that "bombing out while compiling" is a fairly poor problem description. Even if someone wants to do something about it ... where can we possibly start? As a developer, we should know better. $0,02 JensG -Ursprüngliche Nachricht- From: Allen George Sent: Wednesday, March 14, 2018 6:21 PM To: dev@thrift.apache.org ; dev@thrift.apache.org Subject: Re: Problems compiling master dotnet and csharp on ubuntu-xenial docker I'll try track it down. It may be a "make -j2" issue aka. operator error): I notice that c_glib is unable to compile properly if I run more than a single job. Allen From: James E. King, III Sent: Wednesday, March 14, 2018 12:43:34 PM To: dev@thrift.apache.org Subject: Re: Problems compiling master dotnet and csharp on ubuntu-xenial docker The xenial autotools.sh script (which runs "make check", not sure about tutorials) is passing on CI. I assume tutorials are built with one of our CI jobs! - Jim On Wed, Mar 14, 2018 at 12:23 PM, Allen George wrote: > Is anyone having problems compiling master dotnet and csharp on > ubuntu-xenial docker? It appears to be bombing out while trying to compile > the tutorial. > > Allen >
[jira] [Created] (THRIFT-4522) d-cpp_binary_buffered-ip-ssl cross test shows a dlang binary protocol issue
James E. King, III created THRIFT-4522: -- Summary: d-cpp_binary_buffered-ip-ssl cross test shows a dlang binary protocol issue Key: THRIFT-4522 URL: https://issues.apache.org/jira/browse/THRIFT-4522 Project: Thrift Issue Type: Bug Components: D - Library Affects Versions: 0.11.0 Environment: docker-artful ./bootstrap.sh ./configure make precross test/test.py --server d --client cpp --regex '.*binary_buffered-ip-ssl.*' Reporter: James E. King, III {noformat} testBinary(siz = 0) *** FAILED *** testBinary failed: unknown result {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (THRIFT-4476) Typecasting problem on list items
[ https://issues.apache.org/jira/browse/THRIFT-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16404002#comment-16404002 ] ASF GitHub Bot commented on THRIFT-4476: Github user ozymaxx commented on the issue: https://github.com/apache/thrift/pull/1496 All green! :) > 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...
Github user ozymaxx commented on the issue: https://github.com/apache/thrift/pull/1496 All green! :) ---
[jira] [Commented] (THRIFT-4476) Typecasting problem on list items
[ https://issues.apache.org/jira/browse/THRIFT-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16403958#comment-16403958 ] ASF GitHub Bot commented on THRIFT-4476: Github user ozymaxx commented on a diff in the pull request: https://github.com/apache/thrift/pull/1496#discussion_r175284941 --- Diff: build/appveyor/MSVC-appveyor-build.bat --- @@ -39,7 +39,7 @@ CD "%BUILDDIR%" || EXIT /B -DWITH_PYTHON=%WITH_PYTHON% ^ -DWITH_%THREADMODEL%THREADS=ON ^ -DWITH_SHARED_LIB=OFF ^ --DWITH_STATIC_LIB=ON|| EXIT /B +-DWITH_STATIC_LIB=ON ^|| EXIT /B --- End diff -- Yes, you're right. I've removed it now. > 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 pull request #1496: THRIFT-4476: Typecasting problem on list items (+...
Github user ozymaxx commented on a diff in the pull request: https://github.com/apache/thrift/pull/1496#discussion_r175284941 --- Diff: build/appveyor/MSVC-appveyor-build.bat --- @@ -39,7 +39,7 @@ CD "%BUILDDIR%" || EXIT /B -DWITH_PYTHON=%WITH_PYTHON% ^ -DWITH_%THREADMODEL%THREADS=ON ^ -DWITH_SHARED_LIB=OFF ^ --DWITH_STATIC_LIB=ON|| EXIT /B +-DWITH_STATIC_LIB=ON ^|| EXIT /B --- End diff -- Yes, you're right. I've removed it now. ---
[jira] [Commented] (THRIFT-4476) Typecasting problem on list items
[ https://issues.apache.org/jira/browse/THRIFT-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16403957#comment-16403957 ] ASF GitHub Bot commented on THRIFT-4476: Github user ozymaxx commented on a diff in the pull request: https://github.com/apache/thrift/pull/1496#discussion_r175284886 --- Diff: compiler/cpp/src/thrift/generate/t_generator.h --- @@ -268,6 +271,30 @@ class t_generator { return out.str(); } + const std::string emit_double_as_string(const double value) { + std::stringstream double_output_stream; + // sets the maximum precision: http://en.cppreference.com/w/cpp/io/manip/setprecision + // sets the output format to fixed: http://en.cppreference.com/w/cpp/io/manip/fixed (not in scientific notation) + double_output_stream << std::setprecision(std::numeric_limits::digits10 + 1); + + #ifdef _MSC_VER + // strtod is broken in MSVC compilers older than 2015, so std::fixed fails to format a double literal. + // more details: https://blogs.msdn.microsoft.com/vcblog/2014/06/18/ + // c-runtime-crt-features-fixes-and-breaking-changes-in-visual-studio-14-ctp1/ + // and + // http://www.exploringbinary.com/visual-c-plus-plus-strtod-still-broken/ + #if _MSC_VER >= MSC_2015_VER + double_output_stream << std::fixed; + #endif + #else + double_output_stream << std::fixed; --- End diff -- No, in both cases it should use `std::fixed`, that outputs the fixed floating point representation of the number. But if the MSVC compiler is older than 2015, that function is broken, and should not be called. In short, we want the compiler to generate the doubles in the fixed floating point representation if possible. On the Erlang side, if the compiler is older than 2015, we want the compiler to use `std::scientific` since there can be cases where the mantissa is being output as integer, which is illegal. `std::scientific` always outputs the floating points numbers with a floating point mantissa. But if it is 2015 or later, `std::fixed` works correctly and can be used to get rid of the exponent representation. > 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 timeCoefficien
[GitHub] thrift pull request #1496: THRIFT-4476: Typecasting problem on list items (+...
Github user ozymaxx commented on a diff in the pull request: https://github.com/apache/thrift/pull/1496#discussion_r175284886 --- Diff: compiler/cpp/src/thrift/generate/t_generator.h --- @@ -268,6 +271,30 @@ class t_generator { return out.str(); } + const std::string emit_double_as_string(const double value) { + std::stringstream double_output_stream; + // sets the maximum precision: http://en.cppreference.com/w/cpp/io/manip/setprecision + // sets the output format to fixed: http://en.cppreference.com/w/cpp/io/manip/fixed (not in scientific notation) + double_output_stream << std::setprecision(std::numeric_limits::digits10 + 1); + + #ifdef _MSC_VER + // strtod is broken in MSVC compilers older than 2015, so std::fixed fails to format a double literal. + // more details: https://blogs.msdn.microsoft.com/vcblog/2014/06/18/ + // c-runtime-crt-features-fixes-and-breaking-changes-in-visual-studio-14-ctp1/ + // and + // http://www.exploringbinary.com/visual-c-plus-plus-strtod-still-broken/ + #if _MSC_VER >= MSC_2015_VER + double_output_stream << std::fixed; + #endif + #else + double_output_stream << std::fixed; --- End diff -- No, in both cases it should use `std::fixed`, that outputs the fixed floating point representation of the number. But if the MSVC compiler is older than 2015, that function is broken, and should not be called. In short, we want the compiler to generate the doubles in the fixed floating point representation if possible. On the Erlang side, if the compiler is older than 2015, we want the compiler to use `std::scientific` since there can be cases where the mantissa is being output as integer, which is illegal. `std::scientific` always outputs the floating points numbers with a floating point mantissa. But if it is 2015 or later, `std::fixed` works correctly and can be used to get rid of the exponent representation. ---