I've applied your patch rather than use the whole pull request. I've also fixed the problem with evaluating real operations on constants at compile-time so the tests again work. There's a problem with the test in Visual C Windows 64-bit. I think it's only setting the rounding mode for the SSE2 floating point unit. Currently Poly/ML uses the legacy x87 floating point unit even in 64-bit mode. That's on my TODO list.
If you can check that it all works on the machines you were testing that would be helpful.
Regards, David
On 26/01/2016 14:17, James Clarke wrote:
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 <jrtc27 at jrtc27.com> 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 <David.Matthews at prolingua.co.uk> 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/891e8122dcca36f9c2e9eea5a3eca7cf5de9.... 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 polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml