[squeak-dev] The Trunk: KernelTests-dtl.235.mcz
frank.shearar at gmail.com
Mon Nov 5 12:21:27 UTC 2012
On 5 November 2012 11:44, David T. Lewis <lewis at mail.msen.com> wrote:
> On Mon, Nov 05, 2012 at 07:29:13AM +0000, Frank Shearar wrote:
>> On 4 November 2012 18:09, <commits at source.squeak.org> wrote:
>> > David T. Lewis uploaded a new version of KernelTests to project The Trunk:
>> > http://source.squeak.org/trunk/KernelTests-dtl.235.mcz
>> > ==================== Summary ====================
>> > Name: KernelTests-dtl.235
>> > Author: dtl
>> > Time: 4 November 2012, 1:08:04.014 pm
>> > UUID: de45cee9-3416-4fd8-a216-b5cafe70ee57
>> > Ancestors: KernelTests-ul.234
>> > As of Kernel-cmm.671 Timespans created in the context of an offset will start in that offset, and when no context is available the defaultOffset for a Timespan will be zero. This affects a TimeStamp created from a string representation of itself, which will now have zero offset (UTC). Update TimeStampTest to reflect to this behavior.
>> > =============== Diff against KernelTests-ul.234 ===============
>> This fixes two more failing tests, bringing us to:
>> * Tests.Localization.LocaleTest.testLocaleChanged (for which we need
>> to find a preference that differs between the 'en' and 'ja' locales')
>> * Tests.Release.ReleaseTest.testNoObsoleteClasses (failing because
>> some of the Monticello tests don't properly clear up after themselves)
>> and, if you're running a Cog VM, also:
> Of the remaining three failures:
> 1) ReleaseTest>>testNoObsoleteClasses
> I cannot reproduce this in my own image. I've tried running the test suite a
> number of times both with and without the HudsonTools loaded, and this test
> still passes. On squeakci.org, the error message is pointing us to this:
> Error Message
> AnObsoleteMCMockClassA, AnObsoleteMCMockASubclass, AnObsoleteMCMockClassB,
> AnObsoleteMCMockClassD, AnObsoleteMCMockClassE, AnObsoleteMCMockClassF,
> AnObsoleteMCMockClassG, AnObsoleteMCMockClassH and AnObsoleteMCMockClassI
> are obsolete
> This suggests some kind of leftover junk from the Monticello tests, but I
> cannot explain the reason.
Yes, exactly: Levente's handy debugging info tells us that the
ReleaseTest test itself is fine. It's failing correctly because there
_are_ Undeclared things, left over from the dirty Monticello tests.
> 2) LocaleTest>>testLocaleChanged
> If someone can offer a suggestion as to how this should work, great.
> Otherwise it is an expected failure. IMO we should give it another 24 hours
> and if nobody speaks up, mark it as expected failure for resolution in the
> next release.
> 3) LargeNegativeIntegerTest.testMinimumNegativeIntegerArithmetic
> This is a VM capability issue (passes on VMs with the necessary update).
> It is not something that can or should be addressed in the image, therefore
> IMO it should not block the 4.4 release.
Ideally we'd have it an expected failure on a Cog VM and passing in
the newer interpreter VMs, but I agree that we shouldn't delay 4.4 any
More information about the Squeak-dev