Hi David (cc’d mailing list back in), Of course "bytes 00 00 00 00 00 followed by 00 00 00/01/02" is meant to be "bytes 00 00 00 00 followed by 00 00 00 00/01/02".
Regards, James > On 26 Jan 2016, at 14:13, James Clarke <[email protected]> wrote: > > Hi David, > I initially tried to do something like you did (I had val supported = > (setRoundingMode TO_NEAREST; true) handle Fail _ => false or similar, and > wrapped the whole thing in one if succeeded let ... in () end else ()), but > ran into issues where it was failing on x86; I imagine that was because the > compiler was performing the operations on constants at compile-time like you > said, as it didn’t seem to be following the rounding mode. > > Yes, when I was making the S/390 port, all the streams had streamNo 0 (bytes > 00 00 00 00 00 followed by 00 00 00/01/02), so it thought fd 1 and 2 had > closed early, causing polyimport to exit with status code 1 without printing > anything. The same thing was happening on big-endian 64-bit PPC. > > Regards, > James > >> On 26 Jan 2016, at 14:05, David Matthews <[email protected]> >> wrote: >> >> Hi James, >> I was trying to separate out the change to the tests from the change to >> reals.cpp. I don't like the idea of changing the test driver and I'd prefer >> to alter the test itself to deal correctly with the fact that >> setRoundingMode may raise an exception. I'm aware that it doesn't do that >> at the moment and it will need your patch or something like it. >> >> You're right that the change I've made is wrong and will also catch the >> exception raised in "check". Fixing that has, though, shown up a different >> bug where the compiler is trying to perform the real operations on constants >> at compile-time before the rounding mode has been set. That didn't show up >> when they were all top-level expressions. >> >> On your other patch: Was there an issue with the "streamNo" that caused you >> to make that change? I can see the possibility that unsigned might be >> different from POLYUNSIGNED (it certainly is on Windows/X64) and that the >> effect could be to set the wrong part of a word. I'll have to make some >> further changes because there are now warnings on Windows/64-bit. >> >> Regards, >> David >> >> On 26/01/2016 12:43, James Clarke wrote: >>> Hi, >>> I notice you committed >>> https://github.com/polyml/polyml/commit/891e8122dcca36f9c2e9eea5a3eca7cf5de9f191. >>> However, as it stands, on armel the calls do not raise an exception like >>> https://github.com/polyml/polyml/pull/16, which could be misleading for the >>> user, as as far as they are aware setting the mode has succeeded (and >>> getting the mode may return the new mode). Also, unless I’m mistaken, you >>> have effectively just completely disabled that test on every platform, as >>> any failure will be caught. >>> >>> Regards, >>> James >>> >>> >>> >>> _______________________________________________ >>> polyml mailing list >>> [email protected] >>> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml >>> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ polyml mailing list [email protected] http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
