I’m confused by the first solution? If your “home” directory is not writable, then all of the Serialization tests that involve writing to a file, should fail - and not just the FastRandom… test? Execution of HTM.Java’s tests depends on the user being able to write their own directory. If you are executing this code on your own machine, I would think that you would want to correct the directory permissions, not alter the test?
What operating system are you running?
These tests run on Mac and Linux operating systems, and I would assume Windows because I haven’t heard from any Windows users that there are any problems? Can any Windows users out there verify this? I would appreciate hearing from any Windows users about this?
Since the builds run fine, I would look for OS or user account subtleties which could alter the output of these tests rather than change the tests. As far as I have seen, there are no problems at all with the tests? The second test takes-over the System OutputStream (PrintStream), and maybe there is an account setting which prohibits this in some way on the machine or on the account you are using? Also if you look at the ComparisonFailure of the 2nd test above, you see the the two comparisons are comparing two Arrays and not two integers? It’s as if the types are altered on your machine somehow? The output stream seems to be converting the types (though they are exactly the same:
83200 == 83200 ). --> converting longs to integer arrays?
This is what is producing the output:
long s = 2858730232218250L;
long e = (s >>> 35);
System.out.println("e = " + e);
…as you can see, the value outputted concatenates a
long on to a String (
"e = "), and at that point on your OS, it seems to be converting the type?
This test is not important and if the other 600 or so tests all pass, then I wouldn’t worry about this one because the ability to co-opt the OutputStream is not necessary in order to run HTM.Java, that is just a edge case that I was testing.