[jira] [Commented] (THRIFT-4489) Unix domain socket support for NodeJS client

2018-03-18 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/THRIFT-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2018-03-18 Thread danielhtshih 
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

2018-03-18 Thread Jens Geyer 
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

2018-03-18 Thread James E. King, III (JIRA) 
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

2018-03-18 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/THRIFT-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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...

2018-03-18 Thread ozymaxx 
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

2018-03-18 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/THRIFT-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (+...

2018-03-18 Thread ozymaxx 
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

2018-03-18 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/THRIFT-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 timeCoefficients = [24.1,

[GitHub] thrift pull request #1496: THRIFT-4476: Typecasting problem on list items (+...

2018-03-18 Thread ozymaxx 
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. 


---