<body><div id="__MailbirdStyleContent" style="font-size: 12pt;font-family: calibri;color: #000000">
Hi Tim,<div><br></div><div>you can also overwrite #defaultTimeOut in UserInterfaceThemeTest and make use of PreferenceWizardMorph >> #hasLowPerformance, whose implementation we might improve in the future.</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div><blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">
<p style="color: #AAAAAA; margin-top: 10px;">Am 26.09.2017 01:44:23 schrieb David T. Lewis <lewis@mail.msen.com>:</p>On Mon, Sep 25, 2017 at 02:43:28PM -0700, tim Rowledge wrote:<br>> I tried running the tests on UserInterfaceThem to check I hadn???t broken too much and as is so often the case on slower machines some of the tests timed out. It???s not a simply replicatable thing either, with each run producing different tests that ???fail??? this way.<br>> <br>> So the obvious thing to day was <br>> a) add a timeout: pragma to the tests that seem to be slow<br>> b) add an option to profile an individual test<br>> <br>> While running these to play with them I managed to occasionally lock up the input process, which I???d make a wild guess might be something to do with the debugging etc in the testrunner code. It???s not reliable enough to get a good handle on it. It did, however manage to completely lock up the Pi on one occasion - not merely Squeak but the entire Pi. Attempts to login remotely had no effect. Naughty, naughty somewhere in the stack.<br>> <br>> Whilst writing this little extension I noticed some code of a form I???m not keen on. Perhaps there is a good solid reason for it to be like this that I???m unaware of - <br>> runFailures<br>> self result instVarNamed: 'failures' put: Set new.<br>> self runSuite: self suiteFailures.<br>> (similar in runErrors)<br>> There???s not often a good reason to use #instVarNamed:put: and it???s sufficiently odd that I have to wonder if there is a hidden subtlety making it appropriate.<br>> <br><br>I am going to take a wild guess at this one, just to see if I can get<br>it right. My theory is that classes such as TestResult in the underlying<br>test framework are shared across Smalltalk dialects, so the author of<br>the test runner UI wanted to avoid touching those classes. There is no<br>TestResult>>failures: accessor, and rather than add the accessor, the UI<br>author (lr) elected to just poke the value in using #instVarNamed:put:<br>instead.<br><br>Dave<br><br><br>
</blockquote>
</div></body>