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

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