2012/7/27 Frank Shearar <frank.shearar at gmail.com>:
> On 26 July 2012 22:35, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>>
>> On Thu, Jul 26, 2012 at 3:59 AM, Levente Uzonyi <leves at elte.hu> wrote:
>>>
>>> On Thu, 26 Jul 2012, Frank Shearar wrote:
>>>
>>>> In a freshly updated trunk we have 3184 out of 3157 tests passing. We
>>>> have 16 expected failures, and 11 failures, the latter being:
>>>> * BecomeTest>>#testBecomeIdentityHash
>>>
>>>
>>> This is failing due to a VM bug. There's a fix for it somewhere, but it
>>> seems like it's not integrated into Cog yet. Explore this to see that two
>>> consecutive objects share the same identityHash:
>>>
>>> Array new: 10 streamContents: [ :stream |
>>>         1 to: 10 do: [ :e | stream nextPut: Object new identityHash ] ]
>>
>>
>> IMO this isn't a bug.  The identity hash changes at least every other
>> object.  Hashes don't have to be unique.  But they do have to be
>> well-distributed.  With 12 bits of identityHash Cog does fine basing its
>> identityHash on the allocation pointer.  The above will wrap around after
>> 8192 allocations, and provide 4096 distinct hashes (the maximum available).
>> So the test needs rewriting to be more statistical.  The rationale for this
>> is to speed up allocation.  Instead of a read-modify-write cycle to turn the
>> crank of a pseudo-random generator there's a masking of the allocation
>> pointer, which has to be read anyway to allocate an object.  BTW, the
>> *right* way to implement this is to lazily allocate hashes, but for that
>> there needs to be a flag (e.g. an identityHash of 0) to mark an object as
>> not yet having a hash but existing Squeak images (because of the old
>> definition) use 0 as a valid hash, so lazy hashes requires either a header
>> bit (not enough of those) or an image change (which is my plan, as part of
>> the new object representation).
>
> If it's not a bug, let's nuke the test. We need to get to a position
> where we have a green light.
>
> frank
>

If I understood Eliot correctly, it would suffice to keep a pointer
alive to the created objects...

preserveObjectsFromGarbageCollection := IdentitySet new.
Array new: 10 streamContents: [ :stream |
         1 to: 10 do: [ :e | stream nextPut:
(preserveObjectsFromGarbageCollection add: Object new) identityHash ]
]

Nicolas

>>>> * ExceptionTests>>#testHandlerFromAction
>>>
>>>
>>> This is more like a feature request, the current exception handling
>>> mechanism doesn't work like this.
>>>
>>>> * LocaleTest>>#testLocaleChanged
>>>
>>>
>>> A bug introduced during the GetText integration.
>>>
>>>
>>>> * MCFileInTest>>#testStWriter
>>>> * MCMczInstallerTest>>#testInstallFromFile
>>>> * MCMczInstallerTest>>#testInstallFromStream
>>>
>>>
>>> Some old and funky MC issues, if you run the tests one or two more times,
>>> they somehow pass.
>>>
>>>> * PackageDependencyTest>>#testMultilingual
>>>
>>>
>>> Looks okay, just update the dependencies.
>>>
>>>> * PackageDependencyTest>>#testSystem
>>>
>>>
>>> This one is a side effect of the GetText integration. Not sure if
>>> NaturalLanguageTranslator should use TextDomainManager or if it should be
>>> part of the System package. Also not sure about other dependencies here
>>> either.
>>>
>>>> * RWBinaryOrTextStreamTest>>#testExisiting
>>>
>>>
>>> Another feature request, which changes the semantics of ReadWriteStream.
>>> Not implemented yet, because it breaks some code, so it requires a larger
>>> rewrite.
>>>
>>>> * ReleaseTest>>#testNoObsoleteClasses
>>>
>>>
>>> As you described, some TestCases hold references to obsolete classes and
>>> the TestRunner holds the reference to the TestCases.
>>>
>>>> * SocketTest>>#testSendTimeout
>>>
>>>
>>> Either a bug or just some network problem, works for me on windows.
>>>
>>>
>>> Levente
>>>
>>>
>>>>
>>>> ReleaseTest>>#testNoObsoleteClasses lists a bunch of what look to be
>>>> test artifacts: things like
>>>> AnObsoleteAutoGeneratedClassForTestingSystemChanges. ChangeHooksTest
>>>> and ClassRenameFixTest look to be the culprits. How do we make these
>>>> two guys not interfere with ReleaseTest? (Or, how do we nuke the
>>>> obsolete classes created by these guys?)
>>>>
>>>> PackageDependencyTest>>#testExisiting [sic] and #testMultilingual
>>>> looks like they need updating. I don't know if these dependencies
>>>> SHOULD be there, but they ARE there. I'll fix them to reflect reality,
>>>> but if they shouldn't be there, please raise a Mantis report to remove
>>>> the dependency!
>>>>
>>>> I suspect that SocketTest might well involve platform dependencies: it
>>>> fails on my machine, an Ubuntu Lucid Lynx running the latest Cog VM.
>>>>
>>>> I'd really like to have a green test status before we ship 4.4, so I'm
>>>> asking for folks to take a look at the above tests (I'll do the
>>>> PackageDependencyTest ones) and see if anyone can make them green? And
>>>> then maybe, for bonus brownie points, see if we can reduce the number
>>>> of expected failures?
>>>>
>>>> Thanks!
>>>>
>>>> frank
>>>>
>>>>
>>>
>>
>>
>>
>> --
>> best,
>> Eliot
>>
>>
>>
>>
>