On Sun, Dec 26, 2010 at 08:16:22AM +0100, Andreas Raab wrote:
On 12/24/2010 9:35 PM, David T. Lewis wrote:
On Fri, Dec 24, 2010 at 03:41:23PM -0300, Jecel Assumpcao Jr. wrote:
Ken G. Brown wrote on Wed, 22 Dec 2010 23:19:45 -0800
I think too, that it would be good to coordinate with Matthew F. To be sure the Croquet stuff is operational in 4.2.
Yes, this was actually mentioned in the last meeting report -
http://squeakboard.wordpress.com/2010/12/21/meeting-report-for-december- 21-2010/
If I understood correctly, he will continue to track Trunk and doesn't feel that an incomplete merge in 4.2 will be a problem. He did mention the "FloatMath plugin issue" and that it would be good to have that solved in 4.2, but I have not been paying attention to this discussion.
I think that the "FloatMath plugin issue" is Mantis 0007583: Float does not use FloatMathPlugin for bit-consistent float math across platforms.
I went ahead and pushed the changes. They do look reasonable to me but please everyone give it a shot and run all the float tests to ensure it works on your favorite platform as well. In short, if all the tests in KernelTests-Numbers pass, we're good, if any fail, please report back with details.
Cheers,
- Andreas
(cc to vm-dev list)
I have found an additional issue with the FloatMath updates. When running on a VM compiled for 64 bits, an updated trunk image hangs up with no input event processing and no display updates.
This is on a Linux VM compiled with no optimization (CFLAGS='-g -m64 -O0).
The problem is related to Float>>fractionPart. If this method is reverted to the prior version, or if the FloatMathPlugin is not present, the image no longer hangs.
The primitive in question is FloatMathPlugin>>primitiveFractionalPart which presumably has a bug related to pointer size. The bug is exposed by compiling with 64 bit pointers, and the updated trunk image will hang up if the primitive is being called by Float>>fractionPart.
The FloatMathPlugin>>primitiveFractionalPart method looks fine (variables all declared correctly). The error occurs within the __ieee754_modf(rcvr, &trunc) function call, which produces completely bogus results when compiled -m64. This function is implemented as modf() in fdlibm. A stand-alone C test program confirms that the bug is in the library function itself.
Presumably this bug would affect Mac VMs compiled for 64-bits, and I think there are a number of these in circulation (though I do not know if they include the FloatMathPlugin).
Dave