On Tue, 4 Jan 2011, David T. Lewis wrote:

> On Tue, Jan 04, 2011 at 08:59:57AM +0100, Levente Uzonyi wrote:
>> On Mon, 3 Jan 2011, David T. Lewis wrote:
>>
>>> On Mon, Jan 03, 2011 at 08:27:19PM -0600, Chris Muller wrote:
>>>> After updating to 10853 I can run all tests and get the same few
>>>> failures we've been seeing.
>>>>
>>>> However, after trying to run
>>>>
>>>>  ReleaseBuilderTrunk prepareNewBuild
>>>>
>>>> saving the image, and then running the tests, the VM crashes in the
>>>> new FloatConsistencyTests>>#testCos.  Even when I run with the
>>>> standard interpreter.
>>>>
>>>> Is this the proper script we execute to create new (semi-compact)
>>>> images?  It does shave about 5MB off the image size, which is nice,
>>>> but something may have got broke with the new Float changes.
>>>>
>>>> - Chris
>>>
>>> Eeek! Now I see the problem. This is a problem in the FloatMathPlugin
>>> that is present in many of the current VMs, and that will affect
>>> users who run the updated image with the older (existing) VM. Details
>>> are on Mantis here:
>>> http://bugs.squeak.org/view.php?id=7592
>>>
>>> and discussed on the list in this thread:
>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-December/156124.html
>>>
>>> The issue will not be present in future VM builds, but if definitely
>>> affects the current installed base.
>>>
>>> In my view, we should revert the FloatMathPlugin changes in
>>> Kernel-ar.531 for the Squeak 4.2 release, then reapply them to
>>> the update stream immediately after the release.
>>>
>>> I believe that Matthew Fulmer indicated that this would be OK for
>>> his Cobalt work (if I interpret his message correctly):
>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-December/156139.html
>>>
>>> Does anyone disagree with this? i.e. that the FloatMathPlugin fixes
>>> in Kernel-ar.531 should be temporarily reverted, then reapplied
>>> after the Squeak 4.2 image is released?
>>
>> I don't think we should revert all the changes, just the primitives that
>> are broken on some platforms. This way we can keep all other improvements.
>
>> From a change management point of view, I think it may be less confusing
> to revert and re-apply the changes as a complete set. That way your
> image either has the FloatMathPlugin fixes or it does not. If it has
> them, you cannot use a broken VM, period.

That's doable too. Note that we can't really revert changes in trunk, just 
undo and redo them, otherwise already updated images will break.

>
>> Btw, is there a way to use an external plugin instead of the internal
>> version? If yes, then we can provide prebuilt versions of FloatMathPlugin
>> to patch existing VMs.
>>
>
> This should not be necessary. The issue is has been diagnosed, Ian has
> applied the fixes to Subversion, and it is fixed for all new VMs.
>
> My concern is for the installed base of VMs that people have on their
> systems today. People will download the new release and try the image.
> They may or may not install an updated VM. For all the folks who download
> the 4.2 release and try out the new image, we don't want to have it
> crash just because they are using the VM that is already installed on
> their system.

That's exactly what I meant when I wrote "to patch existing VMs". If the 
external plugin can override the broken internal plugin, then shipping the 
images with the fixed plugin can help in this case.


Levente

>
> I would expect that most of the folks who care about the FloatMathPlugin
> fixes are going to be following the update stream anyway, so reapplying
> the fixes immediately after the 4.2 release should work fine for them
> too.
>
> Dave
>
>
>