Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
Thanks! I have just caught the meaning of squash since it's been the first
time i try to contribute an open source project. I will squash all into a
single one and let you know from here.
---
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1496
Yes, however, it needs to be squashed to a single commit. I would prefer
if you did that, but I can do it if you really need me to. It's just a lot
more work for the committers to do that, and we
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
All green! :)
---
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
@jeking3 the build results have come out.
---
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
I have reverted the changes on passing the compiler flag to the testers,
and modified the double emitter.
---
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1496
If there's a way to fix it in the compiler so that it works properly,
that's much better. Having compiler-version-specific branches in the thrift
compiler to handle floating point oddities like
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
@jeking3 or another alternative path to go: emitting double can depend on
the msvc compiler version. If the compiler version is 2013 or less, we can
ignore using fixed.
---
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
@jeking3 , I will now re-enable the tests. But please note that the problem
is at the C++ compiler level. The pre-2015 versions of the Visual Studio C++
compilers uses a different parsing and
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1496
You may be missing my point here. Regardless of the compiler used to build
the thrift compiler, whether it is gcc-4.6, clang-6.0, MSVC 2010, MSVC 2013,
MSVC 2017, the floating constants emitted
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
Okay, I will add a condition on the tests. The values to do the assertions
with will depend on the compiler.
---
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1496
Need to squash to one commit, ideally, to make a merge easier, and fix the
issue causing older MSVC compilers (which people still use...) to generate
different floating constants than other
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
Btw, what's the full name of the test which you want to succeed? I squashed
to another commit and will take a look if this test has passed or not (I hope
there is not something wrong related to my
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1496
Thanks for dealing with the relatively unstable CI. Our project has
support for 25 languages, so needless to say without a fixed build environment
(which is impossible, since packages change over
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
@jeking3 Forget about what I said on Travis. There is only 1 failure in
Apache arsenal of Travis (at `cross-test`) as follows:
```
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
The build on the `CYGWIN x86` (see
https://ci.appveyor.com/project/ozymaxx/thrift/build/job/09xqx9b54efog55o for
more details) machine has broken. Here is the error that I got:
```
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
I have just disabled my new tests on `MSVC2013` builders and kicked a
build. Let's see what happens.
If the tests also fail on the `CYGWIN` machine, I will also write out new
tests for the x86
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1496
I put the MSVC2013 job back in to make sure we had some backwards
compatibility... glad I did. I wonder if we have 32-bit issues with double in
general in thrift?
---
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
The AppVeyor builder with the `MSVC2013` configuration generates large
double constants differently as the old `MSVC2010` configuration used to do. So
I will add a condition to not do the
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1496
Appveyor: It looks like I broke the build yesterday with a check-in that I
did not run through CI. I am fixing it.
Travis: c_glib, that's new; npm; that might be an intermittent failure
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
I merged the changes in the master branch into mine, and ran the builds.
There are still some errors:
On AppVeyor:
```
3125"C:\projects\build\MSVC2017\x64\INSTALL.vcxproj"
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1496
The current master is fairly clean except for a recurring dlang issue.
Squash and rebase on master. Squash to one commit please.
---
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
I finalized the changes, however there are a couple of errors in my builds
which I think are irrelevant to my changes.
Here are the links to my build results (please let me know if you
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
Okay, I will open it back once I am done.
---
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1496
Sourceforge was down for a while. I am working on getting the builds back
to green (passing). I recommend that you keep your pull request squashed to
one commit. In fact since you are doing
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
Two errors at the initial steps of my builds:
* The one in Travis (happening in multiple builds):
```
Resolving master.dl.sourceforge.net (master.dl.sourceforge.net)...
216.105.38.12
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1496
You can fork the project and set up your own Travis CI and Appveyor builds,
and submit pull requests into your fork to kick off builds, and you will not
contend with the rest of the apache arsenal
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
The AppVeyor builds stay in the queue for a long time. Is there any
possibility to run the builds more quickly?
---
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
It appears that there is another compilation problem in Erlang. In the file
`test/DoubleConstantsTest.thrift`, the double literal `100.1` is compiled
to `1e+06`. However, Erlang does not accept
28 matches
Mail list logo
