[squeak-dev] Re: Failing tests
leves at elte.hu
Tue Dec 15 19:35:55 UTC 2009
On Mon, 14 Dec 2009, Andreas Raab wrote:
> Levente Uzonyi wrote:
>> I'd like to have less failing tests in the trunk. For this, we have to make
>> decisions/anwser questions.
> Thanks for taking the time to go through these tests carefully!
>> Should we change the default, so that LongTestCases are run when selected
>> in the Test Runner? (Or one could add a chechbox to the gui which would let
>> the user to decide if she/he wants to run long tests? Or this could be a
>> preference, etc.)
> I would opt for a preference or a checkbox in the UI.
I added a preference, maybe someone will update the gui.
>> Mirror primitives do not exists in the current vm. Will the vm have mirror
>> primitives? Should we keep the tests? Removing these would "fix" 6 errors.
> IIRC, the mirror primitive tests were designed to test that certain
> primitives will be applied to the "last argument" instead of only to the
> receiver. I.e., such that one could do both:
> "answer the class of the receiver"
> <primitive: 1234>
> as well as:
> Mirror>>classOf: anObject
> <primitive: 1234>
> It would be good if we could keep those working (perhaps ask Eliot for an
We should definitely keep the tests. After a bit of googling I found
Eliot's email which didn't get much attention:
This explains everything about mirror primitives. I wonder why these
changes aren't integrated into VMMaker. (Note that ContextPart >>
#objectClass: is missing from the attached source, I added an
implementation to the trunk). I marked the failing tests as expected
>> Building a vm with the latest VMMaker lets 6 failing test pass
>> (AllocationTest, BitBltTests). It also avoids crashing linux as reported
> I would opt to fail the crashing AllocationTests on Linux, i.e., something
> "the test currently crashes the vm on unix"
> Smalltalk platformName = 'unix' ifTrue:[^self assert: false].
> mark it expected failure, and later, when we have fixed VMs, allow the test
> to run.
Done, feedback is welcome.
>> And it also yields slight performance improvement because of the
>> primitiveNextPut fix. Why aren't vm releases available with these fixes?
> Because nobody's been asking for then :-) A post to vm-dev might help.
I'm on it.
>> There are two "great challenges" which would let most other failing tests
>> - fixing traits (the issues are solved in pharo, but one has to extract and
>> integrate them)
>> - fixing the decompiler (there's an issue with temporary variable
>> declarations in inlined blocks)
>> Is anybody working on these?
> I'm working on the former (time permitting) and I'd check with Eliot for the
>> - MorphicToolBuilderTests>>#testGetButtonSideEffectFree
> I can take care of that.
> - Andreas
More information about the Squeak-dev