4.0.3-2202 - core dump

> 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

>
> Segmentation fault
>
> 2035040100 FloatConsistencyTests>testCos
> 2035040008 FloatConsistencyTests>floatTest:
> 2035038632 BlockClosure>on:do:
> 2035038448 BlockClosure>on:do:
> 2035039280 BlockClosure>ensure:
> 2034750500 FloatConsistencyTests>floatTest:
> 2034438848 FloatConsistencyTests>testCos
> 2034438756 TestCase>performTest
> 2034438652 TestCase>runCase
> 2034438560 BlockClosure>on:do:
> 2034438468 TestCase>timeout:after:
> 2034438376 BlockClosure>ensure:
> 2034437496 TestCase>timeout:after:
> 2034437340 TestCase>runCase
> 2034437248 BlockClosure>ensure:
> 2034437116 TestCase>runCase
> 2034437024 TestResult>runCase:
> 2034436904 BlockClosure>on:do:
> 2034436760 TestResult>runCase:
> 2034436668 BlockClosure>on:do:
> 2034436540 TestResult>runCase:
> 2034436448 TestCase>run:
> 2034436356 TestRunner>runTest:
> 2034436264 TestRunner>runSuite:
> 2034436172 Collection>do:displayingProgress:every:
> 2034431328 OrderedCollection>do:
> 2034431192 Collection>do:displayingProgress:every:
> 2034431100 ProgressInitiationException>defaultMorphicAction
> 2034430864 BlockClosure>on:do:
> 2034430772 ProgressInitiationException>defaultMorphicAction
> 2034430680 BlockClosure>ensure:
> 2034430332 ProgressInitiationException>defaultMorphicAction
> 2034430240 ProgressInitiationException>defaultAction
> 2034430148 UndefinedObject>handleSignal:
> 2034430056 ContextPart>handleSignal:
> 2034429964 Exception>signal
> 2034429824 ProgressInitiationException>display:at:from:to:during:
> 2034429732 ProgressInitiationException class>display:at:from:to:during:
> 2034429640 MorphicUIManager>displayProgress:at:from:to:during:
> 2034429548 String>displayProgressAt:from:to:during:
> 2034429376 Collection>do:displayingProgress:every:
> 2034429284 Collection>do:displayingProgress:
> 2034429140 TestRunner>basicRunSuite:do:
> 2034429048 BlockClosure>ensure:
> 2034428876 TestRunner>basicRunSuite:do:
> 2034428784 TestRunner>runSuite:
> 2034422956 TestRunner>runAll
> 2034422864 PluggableButtonMorph>performAction
> 2034422772 PluggableButtonMorphPlus>performAction
> 2034422656 PluggableButtonMorph>mouseUp:
> 2034422564 SequenceableCollection>do:
> 2034422472 PluggableButtonMorph>mouseUp:
> 2034422340 PluggableButtonMorphPlus>mouseUp:
> 2034422248 Morph>handleMouseUp:
> 2034422156 MouseButtonEvent>sentTo:
> 2034422064 Morph>handleEvent:
> 2034421972 Morph>handleFocusEvent:
> 2034421792 HandMorph>sendFocusEvent:to:clear:
> 2034421700 PasteUpMorph>becomeActiveDuring:
> 2034421608 BlockClosure>on:do:
> 2034421516 PasteUpMorph>becomeActiveDuring:
> 2034421396 HandMorph>sendFocusEvent:to:clear:
> 2034421304 HandMorph>sendEvent:focus:clear:
> 2034421212 HandMorph>sendMouseEvent:
> 2034421068 HandMorph>handleEvent:
> 2034420892 HandMorph>processEvents
> 2034420768 WorldState>doOneCycleNowFor:
> 2034420676 SequenceableCollection>do:
> 2034420584 WorldState>handsDo:
> 2034420492 WorldState>doOneCycleNowFor:
> 2034420400 WorldState>doOneCycleFor:
> 2034420308 PasteUpMorph>doOneCycle
> 2026531152 Project class>spawnNewProcess
> 2026531020 BlockClosure>newProcess

>
> 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
>
> Segmentation fault
>
> 2035040100  FloatConsistencyTests>testCos
> 2035040008  FloatConsistencyTests>floatTest:
> 2035038632  BlockClosure>on:do:
> 2035038448 BlockClosure>on:do:
> 2035039280  BlockClosure>ensure:
> 2034750500  FloatConsistencyTests>floatTest:
> 2034438848  FloatConsistencyTests>testCos
> 2034438756  TestCase>performTest
> 2034438652 TestCase>runCase
> 2034438560  BlockClosure>on:do:
> 2034438468 TestCase>timeout:after:
> 2034438376  BlockClosure>ensure:
> 2034437496 TestCase>timeout:after:
> 2034437340  TestCase>runCase
> 2034437248 BlockClosure>ensure:
> 2034437116  TestCase>runCase
> 2034437024 TestResult>runCase:
> 2034436904  BlockClosure>on:do:
> 2034436760 TestResult>runCase:
> 2034436668  BlockClosure>on:do:
> 2034436540 TestResult>runCase:
> 2034436448  TestCase>run:
> 2034436356 TestRunner>runTest:
> 2034436264  TestRunner>runSuite:
> 2034436172  Collection>do:displayingProgress:every:
> 2034431328  OrderedCollection>do:
> 2034431192  Collection>do:displayingProgress:every:
> 2034431100  ProgressInitiationException>defaultMorphicAction
> 2034430864  BlockClosure>on:do:
> 2034430772  ProgressInitiationException>defaultMorphicAction
> 2034430680  BlockClosure>ensure:
> 2034430332  ProgressInitiationException>defaultMorphicAction
> 2034430240  ProgressInitiationException>defaultAction
> 2034430148  UndefinedObject>handleSignal:
> 2034430056  ContextPart>handleSignal:
> 2034429964 Exception>signal
> 2034429824  ProgressInitiationException>display:at:from:to:during:
> 2034429732  ProgressInitiationException class>display:at:from:to:during:
> 2034429640  MorphicUIManager>displayProgress:at:from:to:during:
> 2034429548  String>displayProgressAt:from:to:during:
> 2034429376  Collection>do:displayingProgress:every:
> 2034429284  Collection>do:displayingProgress:
> 2034429140  TestRunner>basicRunSuite:do:
> 2034429048  BlockClosure>ensure:
> 2034428876  TestRunner>basicRunSuite:do:
> 2034428784  TestRunner>runSuite:
> 2034422956 TestRunner>runAll
> 2034422864  PluggableButtonMorph>performAction
> 2034422772  PluggableButtonMorphPlus>performAction
> 2034422656  PluggableButtonMorph>mouseUp:
> 2034422564  SequenceableCollection>do:
> 2034422472  PluggableButtonMorph>mouseUp:
> 2034422340  PluggableButtonMorphPlus>mouseUp:
> 2034422248  Morph>handleMouseUp:
> 2034422156 MouseButtonEvent>sentTo:
> 2034422064  Morph>handleEvent:
> 2034421972 Morph>handleFocusEvent:
> 2034421792  HandMorph>sendFocusEvent:to:clear:
> 2034421700  PasteUpMorph>becomeActiveDuring:
> 2034421608  BlockClosure>on:do:
> 2034421516  PasteUpMorph>becomeActiveDuring:
> 2034421396  HandMorph>sendFocusEvent:to:clear:
> 2034421304  HandMorph>sendEvent:focus:clear:
> 2034421212  HandMorph>sendMouseEvent:
> 2034421068  HandMorph>handleEvent:
> 2034420892 HandMorph>processEvents
> 2034420768  WorldState>doOneCycleNowFor:
> 2034420676  SequenceableCollection>do:
> 2034420584 WorldState>handsDo:
> 2034420492  WorldState>doOneCycleNowFor:
> 2034420400  WorldState>doOneCycleFor:
> 2034420308  PasteUpMorph>doOneCycle
> 2026531152 Project  class>spawnNewProcess
> 2026531020 BlockClosure>newProcess
>
>

> 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?

>
> Dave
>
>>
>> Segmentation fault
>>
>> 2035040100 FloatConsistencyTests>testCos
>> 2035040008 FloatConsistencyTests>floatTest:
>> 2035038632 BlockClosure>on:do:
>> 2035038448 BlockClosure>on:do:
>> 2035039280 BlockClosure>ensure:
>> 2034750500 FloatConsistencyTests>floatTest:
>> 2034438848 FloatConsistencyTests>testCos
>> 2034438756 TestCase>performTest
>> 2034438652 TestCase>runCase
>> 2034438560 BlockClosure>on:do:
>> 2034438468 TestCase>timeout:after:
>> 2034438376 BlockClosure>ensure:
>> 2034437496 TestCase>timeout:after:
>> 2034437340 TestCase>runCase
>> 2034437248 BlockClosure>ensure:
>> 2034437116 TestCase>runCase
>> 2034437024 TestResult>runCase:
>> 2034436904 BlockClosure>on:do:
>> 2034436760 TestResult>runCase:
>> 2034436668 BlockClosure>on:do:
>> 2034436540 TestResult>runCase:
>> 2034436448 TestCase>run:
>> 2034436356 TestRunner>runTest:
>> 2034436264 TestRunner>runSuite:
>> 2034436172 Collection>do:displayingProgress:every:
>> 2034431328 OrderedCollection>do:
>> 2034431192 Collection>do:displayingProgress:every:
>> 2034431100 ProgressInitiationException>defaultMorphicAction
>> 2034430864 BlockClosure>on:do:
>> 2034430772 ProgressInitiationException>defaultMorphicAction
>> 2034430680 BlockClosure>ensure:
>> 2034430332 ProgressInitiationException>defaultMorphicAction
>> 2034430240 ProgressInitiationException>defaultAction
>> 2034430148 UndefinedObject>handleSignal:
>> 2034430056 ContextPart>handleSignal:
>> 2034429964 Exception>signal
>> 2034429824 ProgressInitiationException>display:at:from:to:during:
>> 2034429732 ProgressInitiationException class>display:at:from:to:during:
>> 2034429640 MorphicUIManager>displayProgress:at:from:to:during:
>> 2034429548 String>displayProgressAt:from:to:during:
>> 2034429376 Collection>do:displayingProgress:every:
>> 2034429284 Collection>do:displayingProgress:
>> 2034429140 TestRunner>basicRunSuite:do:
>> 2034429048 BlockClosure>ensure:
>> 2034428876 TestRunner>basicRunSuite:do:
>> 2034428784 TestRunner>runSuite:
>> 2034422956 TestRunner>runAll
>> 2034422864 PluggableButtonMorph>performAction
>> 2034422772 PluggableButtonMorphPlus>performAction
>> 2034422656 PluggableButtonMorph>mouseUp:
>> 2034422564 SequenceableCollection>do:
>> 2034422472 PluggableButtonMorph>mouseUp:
>> 2034422340 PluggableButtonMorphPlus>mouseUp:
>> 2034422248 Morph>handleMouseUp:
>> 2034422156 MouseButtonEvent>sentTo:
>> 2034422064 Morph>handleEvent:
>> 2034421972 Morph>handleFocusEvent:
>> 2034421792 HandMorph>sendFocusEvent:to:clear:
>> 2034421700 PasteUpMorph>becomeActiveDuring:
>> 2034421608 BlockClosure>on:do:
>> 2034421516 PasteUpMorph>becomeActiveDuring:
>> 2034421396 HandMorph>sendFocusEvent:to:clear:
>> 2034421304 HandMorph>sendEvent:focus:clear:
>> 2034421212 HandMorph>sendMouseEvent:
>> 2034421068 HandMorph>handleEvent:
>> 2034420892 HandMorph>processEvents
>> 2034420768 WorldState>doOneCycleNowFor:
>> 2034420676 SequenceableCollection>do:
>> 2034420584 WorldState>handsDo:
>> 2034420492 WorldState>doOneCycleNowFor:
>> 2034420400 WorldState>doOneCycleFor:
>> 2034420308 PasteUpMorph>doOneCycle
>> 2026531152 Project class>spawnNewProcess
>> 2026531020 BlockClosure>newProcess
>
>

>
> Float>>arcCos (NaNError is Undeclared)
> Float>>arcCosH (NaNError is Undeclared)
> Float>>arcSin (NaNError is Undeclared)
> Float>>arcSinH (NaNError is Undeclared)
> Float>>arcTan (NaNError is Undeclared)
> Float>>arcTan: (NaNError is Undeclared)
> Float>>arcTan: (NaNError is Undeclared)
> Float>>arcTanH (NaNError is Undeclared)
> Float>>cos (NaNError is Undeclared)
> Float>>cosH (NaNError is Undeclared)
> Float>>exp (NaNError is Undeclared)
> Float>>fractionPart (NaNError is Undeclared)
> Float>>hypot: (NaNError is Undeclared)
> Float>>hypot: (NaNError is Undeclared)
> Float>>ln (NaNError is Undeclared)
> Float>>log (NaNError is Undeclared)
> Float>>sin (NaNError is Undeclared)
> Float>>sinH (NaNError is Undeclared)
> Float>>tan (NaNError is Undeclared)
> Float>>tanH (NaNError is Undeclared)
> Float>>timesTwoPower: (NaNError is Undeclared)
>
> They probably were there before but I usually don't have Transcript open ...
>
> Markus
>
>
>>
>> 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
>>
>> Segmentation fault
>>
>> 2035040100  FloatConsistencyTests>testCos
>> 2035040008  FloatConsistencyTests>floatTest:
>> 2035038632  BlockClosure>on:do:
>> 2035038448 BlockClosure>on:do:
>> 2035039280  BlockClosure>ensure:
>> 2034750500  FloatConsistencyTests>floatTest:
>> 2034438848  FloatConsistencyTests>testCos
>> 2034438756  TestCase>performTest
>> 2034438652 TestCase>runCase
>> 2034438560  BlockClosure>on:do:
>> 2034438468 TestCase>timeout:after:
>> 2034438376  BlockClosure>ensure:
>> 2034437496 TestCase>timeout:after:
>> 2034437340  TestCase>runCase
>> 2034437248 BlockClosure>ensure:
>> 2034437116  TestCase>runCase
>> 2034437024 TestResult>runCase:
>> 2034436904  BlockClosure>on:do:
>> 2034436760 TestResult>runCase:
>> 2034436668  BlockClosure>on:do:
>> 2034436540 TestResult>runCase:
>> 2034436448  TestCase>run:
>> 2034436356 TestRunner>runTest:
>> 2034436264  TestRunner>runSuite:
>> 2034436172  Collection>do:displayingProgress:every:
>> 2034431328  OrderedCollection>do:
>> 2034431192  Collection>do:displayingProgress:every:
>> 2034431100  ProgressInitiationException>defaultMorphicAction
>> 2034430864  BlockClosure>on:do:
>> 2034430772  ProgressInitiationException>defaultMorphicAction
>> 2034430680  BlockClosure>ensure:
>> 2034430332  ProgressInitiationException>defaultMorphicAction
>> 2034430240  ProgressInitiationException>defaultAction
>> 2034430148  UndefinedObject>handleSignal:
>> 2034430056  ContextPart>handleSignal:
>> 2034429964 Exception>signal
>> 2034429824  ProgressInitiationException>display:at:from:to:during:
>> 2034429732  ProgressInitiationException class>display:at:from:to:during:
>> 2034429640  MorphicUIManager>displayProgress:at:from:to:during:
>> 2034429548  String>displayProgressAt:from:to:during:
>> 2034429376  Collection>do:displayingProgress:every:
>> 2034429284  Collection>do:displayingProgress:
>> 2034429140  TestRunner>basicRunSuite:do:
>> 2034429048  BlockClosure>ensure:
>> 2034428876  TestRunner>basicRunSuite:do:
>> 2034428784  TestRunner>runSuite:
>> 2034422956 TestRunner>runAll
>> 2034422864  PluggableButtonMorph>performAction
>> 2034422772  PluggableButtonMorphPlus>performAction
>> 2034422656  PluggableButtonMorph>mouseUp:
>> 2034422564  SequenceableCollection>do:
>> 2034422472  PluggableButtonMorph>mouseUp:
>> 2034422340  PluggableButtonMorphPlus>mouseUp:
>> 2034422248  Morph>handleMouseUp:
>> 2034422156 MouseButtonEvent>sentTo:
>> 2034422064  Morph>handleEvent:
>> 2034421972 Morph>handleFocusEvent:
>> 2034421792  HandMorph>sendFocusEvent:to:clear:
>> 2034421700  PasteUpMorph>becomeActiveDuring:
>> 2034421608  BlockClosure>on:do:
>> 2034421516  PasteUpMorph>becomeActiveDuring:
>> 2034421396  HandMorph>sendFocusEvent:to:clear:
>> 2034421304  HandMorph>sendEvent:focus:clear:
>> 2034421212  HandMorph>sendMouseEvent:
>> 2034421068  HandMorph>handleEvent:
>> 2034420892 HandMorph>processEvents
>> 2034420768  WorldState>doOneCycleNowFor:
>> 2034420676  SequenceableCollection>do:
>> 2034420584 WorldState>handsDo:
>> 2034420492  WorldState>doOneCycleNowFor:
>> 2034420400  WorldState>doOneCycleFor:
>> 2034420308  PasteUpMorph>doOneCycle
>> 2026531152 Project  class>spawnNewProcess
>> 2026531020 BlockClosure>newProcess
>>
>>
>
>
>
>

> 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.

> 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.

>
>> 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.

>
> 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
>
>
>

> 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?

> > 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 agree.  But, looking in the Version History of the "Kernel" package,
> it looks like the actual packages to revert are:
>
>   Kernel-mtf.527
>   Kernel-ar.528
>   Kernel-ar.529
>   Kernel-ul.530
>   Kernel-ar.531
>
> I can do the work.  For good review, would someone please confirm this?