[
https://issues.apache.org/jira/browse/THRIFT-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051341#comment-15051341
]
Hudson commented on THRIFT-3433:
--------------------------------
SUCCESS: Integrated in Thrift #1764 (See
[https://builds.apache.org/job/Thrift/1764/])
THRIFT-3433 Doubles aren't interpreted correctly Client: Haskell Patch: (nsuke:
rev 7c7d679a127ed5157464b061a7f9bfd40ad2f1fa)
* lib/hs/src/Thrift/Protocol.hs
* lib/hs/Makefile.am
* lib/hs/test/CompactSpec.hs
* lib/hs/test/BinarySpec.hs
* lib/hs/src/Thrift/Transport/Memory.hs
* lib/hs/README.md
* lib/hs/src/Thrift/Protocol/Compact.hs
* lib/hs/CMakeLists.txt
* lib/hs/test/Spec.hs
* lib/hs/LICENSE
* lib/hs/Thrift.cabal
* lib/hs/TODO
> Doubles aren't interpreted correctly
> ------------------------------------
>
> Key: THRIFT-3433
> URL: https://issues.apache.org/jira/browse/THRIFT-3433
> Project: Thrift
> Issue Type: Bug
> Components: Haskell - Library
> Affects Versions: 0.9.3
> Reporter: Tom Lippincott
> Assignee: Aki Sukegawa
> Fix For: 1.0
>
>
> When reading in a string-to-double map from the identical file using the
> Compact protocol, Python gives the correct values:
> ...
> u'roh': -12.012431158160835
> ...
> but Haskell is totally off:
> ...
> ("roh",6.355136015066463e-157)
> ...
> The funny thing is, if I read it into Haskell (and the numbers are all off),
> then write it out to another file, that file still has correct numbers when
> loaded into Python. So it seems that the raw information is being
> (de)serialized correctly at the bit-level, but Haskell isn't interpreting it
> as a double the same way as Python...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
