<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2014/1/14 karl ramberg <span dir="ltr"><<a href="mailto:karlramberg@gmail.com" target="_blank">karlramberg@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">TraitsFileOutTest is failing<div><br></div><div>Correct log attached this time</div><div><br></div><div>Cheers,</div><div>Karl</div></div><div class=""><div class="h5"><div class="gmail_extra"><br></div></div>
</div></blockquote><div>id: #[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]<br></div><div>means the file was closed...<br><br></div><div>I observed increasing failure rate related to randomly closed change log the last few months (particularly when loading/merging with MC), it would be good to identify the root cause...<br>
<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 13, 2014 at 11:53 PM, karl ramberg <span dir="ltr"><<a href="mailto:karlramberg@gmail.com" target="_blank">karlramberg@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I get a prim failed error on a MultiByteFileStream on Windows 8 running the Traits tests.<div>
<br></div>
<div>Cheers,</div><div>Karl</div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 13, 2014 at 10:15 PM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div><div>2014/1/13 Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 11 January 2014 22:55, Frank Shearar <<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>> wrote:<br>
> On 11 January 2014 19:19, tim Rowledge <<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>> wrote:<br>
>><br>
>> On 11-01-2014, at 6:29 AM, Frank Shearar <<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>> wrote:<br>
>><br>
>>> A bunch of the Trait tests fail, despite no one having worked on the<br>
>>> Traits code in quite a while. The symptom is that the tests time out<br>
>>> [1]. I've tried to debug some, only to find that they pass. For<br>
>>> instance, <timeout: 60> sometimes "fixes" the tests.<br>
>>><br>
>>> But the tests shouldn't be failing. Any takers?<br>
>><br>
>> I noticed similar issues when running test on a Pi; being a relatively slow machine it takes longer to do some things and needed a larger timeout value.<br>
>><br>
>> If tests that used to run within the time are now taking longer but still pass if given enough time, that implies to me that either<br>
>> a) the tests are being run on a slower machine due to some system configuration change (are other jobs also running and taking time?)<br>
>> b) something has changed in the execution path to slow down the tested code. Which obviously, ought not be the case.<br>
><br>
> They time out on my beefy work laptop: a 2.7 GHz machine. That's<br>
> probably a higher spec machine than the build server.<br>
><br>
> If I was a betting man I'd be inclined to put my money on (b).<br>
<br>
Attached is the output of MessageTally spyOn: [[TraitCompositionTest<br>
debug: #testAliasCompositions] on: TestFailure do: [#fail]], after<br>
adding <timeout: 60> to the test.<br>
<br>
The leaves are very interesting:<br>
<br>
**Leaves**<br>
43.1% {28650ms} CompiledMethod>>originalTraitMethod:<br>
36.9% {24505ms} Text>>size<br>
9.7% {6425ms} Delay>>wait<br>
3.4% {2239ms} SecurityManager class>>default<br>
1.1% {749ms} CompiledMethod>>checkOKToAdd:at:<br>
<br>
_24 seconds_ in Text >> #size ?! Also,<br>
CompiledMethod>>originalTraitMethod: hasn't changed in 4 years. In<br>
fact the only things that have changed, that I can see, in the code<br>
path are Chris Muller's fixing of TestCase >> #debug and Nicolas<br>
Cellier's cleanup of the Compiler API. Nothing looks even remotely<br>
capable of slowing stuff down this dramatically.<br>
<span><font color="#888888"><br>
frank<br>
</font></span><br></blockquote></div></div><div>I don't get same figures here:<br><br></div><div>1st run:<br></div><div>**Leaves**<br>50.5% {3145ms} CompiledMethod>>originalTraitMethod:<br>18.1% {1125ms} Delay>>wait<br>
11.8% {731ms} MultiByteFileStream>>nextPut:<br>5.1% {316ms} Trait(ClassDescription)>>organization<br>3.3% {206ms} MultiByteFileStream(StandardFileStream)>>open:forWrite:<br>1.7% {108ms} CompiledMethodWithNode>>selector<br>
1.1% {67ms} ByteSymbol(Symbol)>>=<br><br></div><div>2nd run:<br><br></div><div>**Leaves**<br>50.5% {1991ms} CompiledMethod>>originalTraitMethod:<br>15.7% {617ms} MultiByteFileStream>>nextPut:<br>8.8% {346ms} Delay>>wait<br>
4.6% {180ms} MultiByteFileStream(StandardFileStream)>>open:forWrite:<br>3.9% {153ms} Trait(ClassDescription)>>organization<br>2.3% {92ms} ByteSymbol(Symbol)>>=<br>1.5% {59ms} WeakArray class>>finalizationProcess<br>
1.4% {54ms} CompiledMethodWithNode>>selector<br>1.1% {42ms} Array(SequenceableCollection)>>indexOf:startingAt:ifAbsent:<br><br></div><div>Hmm, great variations between 2 runs?<br>I also note presence of AnObsoleteC1/2 as large consumers... Not that healthy.<br>
<br></div><div>With an AndreasSystemProfiler, here are the leaves:<br><br></div><div>1st run:<br></div><div>**Leaves**<br>57.1 (2,518) Array elementsForwardIdentityTo:<br>16.4 (722) StandardFileStream primWrite:from:startingAt:count:<br>
6.5 (288) Symbol flushCache<br>5.7 (252) StandardFileStream primOpen:writable:<br><br></div><div>2nd run:<br></div><div>**Leaves**<br>64.8 (4,436) Array elementsForwardIdentityTo:<br>17.3 (1,183) StandardFileStream primWrite:from:startingAt:count:<br>
4.6 (318) Symbol flushCache<br>4.1 (282) StandardFileStream primOpen:writable:<br><br></div><div>Though I failed to find the direct call to elementsForwardIdentityTo: in the send chain (probably thru becomeForward:)...<br>
<br></div></div></div></div>
<br><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br><br>
<br></blockquote></div><br></div></div>