On Wed, Feb 13, 2013 at 7:54 PM, Andi Vajda <va...@apache.org> wrote: > > On Wed, 13 Feb 2013, Robert Muir wrote: > >> On Tue, Feb 12, 2013 at 3:11 AM, Andi Vajda <va...@apache.org> wrote: >>> >>> I then found that the test case from hell, TestSort.java, has majorly >>> changed again and test_Sort.py needs to be ported again. Sigh. >>> >>> Andi.. >> >> >> I'm not laughing at your expense Andi... but this made me laugh out >> loud multiple times today. >> >> I've done battle with this thing several times, I feel like I always lose! > > > I found lines 170 - 195 particularly clever :-) > > Jokes aside, I did spend a bunch of time of yesterday battling with the > unspelled assumptions made in the Lucene random number generation code in > the Lucene test framework. In particular, it seems that it expects different > threads, sometimes, to get the same random values, no ? (I'm using Python's > random number generator in PyLucene). > > The field cache sanity checker would otherwise complain, sometimes... > > Andi..
in all seriousness I dont like that committers' time is wasted on this. just a day or two ago I created a bug in this thing merging, and mike spent time tracking it down. I'd like to think i'm pretty careful about not breaking things when merging (I think i spent at least an hour merging this file alone very carefully, yet still screwed it up). so i opened https://issues.apache.org/jira/browse/LUCENE-4779 about the randomness: I think this should not be the case. if different threads try to share the same random, actually there should be an exception from the test framework saying that each thread should get its own random (eg. initialized by a long value). So lucene-java tests should not have code that does this: otherwise it really makes test failures difficult to reproduce. Unfortunately I'm not very familiar with what python does here, but I cc'ed Dawid just in case he knows off the top of his head.
