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.

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

Object>>class
   "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 opinion).

> Building a vm with the latest VMMaker lets 6 failing test pass 
> (AllocationTest, BitBltTests). It also avoids crashing linux as reported 
> before
> (http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/142074.html). 

I would opt to fail the crashing AllocationTests on Linux, i.e., 
something like:

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

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

> There are two "great challenges" which would let most other failing 
> tests pass:
> - 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 latter.

> - MorphicToolBuilderTests>>#testGetButtonSideEffectFree

I can take care of that.

Cheers,
   - Andreas