Example for the MuTalk chapter and small changes

[DurieuxPol]

Package MuTalk-Examples contains a class and a test class used for the MuTalk chapter, and executable scripts as extension methods in MTAnalysis class side.

Small changes include :

• don't log the mutant generation if the mutations are already given (mutations are not nil)
• heat map color palette changed to red - yellow - green
• setter for mtAnalysis in MTUtilityAnalysis class

[guillep]

Salut @DurieuxPol there is a broken test in the P11 build, I re-ran it and it failed again, can you check it? The P9 build is broken because of a separate thing, we should fix it separately

[DurieuxPol]

I think I found the issue. It's about this test:

testWithNoTimeForMutantsRunsNoMutants

	| duration analysisTime result |
	"Divide duration by 4 to make sure we never have time for mutants"
	duration := self fixedAnalysisTime / 4.
	analysisTime := [ result := self runAnalysisForDuration: duration ]
		                timeToRun.

	"We never treat mutants because the budget was exceeded running the initial test run, coverage analysis, etc"
	self assert: result numberOfEvaluatedMutants equals: 0

When the test breaks it's because the analysis had time to evaluate mutants. The initial test run, coverage analysis etc don't always take the same time, and sometimes I guess it's way faster the 2nd time (when we compute analysisTime) than the 1st time (when we comput duration), so dividing by 4 is not always enough.
I suggest dividing by 10 to make sure the analysis doesn't have time to evaluate mutants (or at least to leave less chances).

[DurieuxPol]

And the issue doesn't seem to be specific to Pharo 11, I had it also on Pharo 12. It's just quite random given its nature.

[guillep]

Hmm I think it's worth trying with a smaller time. But it's not a solution in the long term :)
Let's try.

In the future if this persists and we don't find a solution maybe it's good to remove those tests?

[DurieuxPol]

I'll do that.
I think the issue is also caused by the fact that the analysis runtime is only a few milliseconds, so dividing it by 4, 10 or whatever doesn't make a big change. If the issue persists in the futur a solution could be to use bigger classes for the analysis, so that dividing the runtime reduces more significantly the duration.

[guillep]

Thanks Pol!