[Vm-dev] Re: [squeak-dev] Trunk test status

[Eliot Miranda]

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


>
>  * 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
>> AnObsoleteAutoGeneratedClassFo**rTestingSystemChanges. 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120726/bc00013b/attachment.htm