On 4/8/13 5:05 PM, "Dawid Weiss" wrote:
>> thought I checked for that but apparently I got confused. I do find it
>> disconcerting that the random seed can get incremented by
>> LuceneTestCase.newDirectory() a different number of times depending on
>> wether or not -Dtests.seed has been set.
>
> thought I checked for that but apparently I got confused. I do find it
> disconcerting that the random seed can get incremented by
> LuceneTestCase.newDirectory() a different number of times depending on
> wether or not -Dtests.seed has been set.
It's not really like that. By passing -Dtests.se
Thanks for that tip Dawid. I'll consider AspectJ some day; that's an
interesting approach.
So as it turns out, I was wrong when I said that the same shapes etc. were
being tested when I switched the directory via the system property. I
thought I checked for that but apparently I got confused. I
: I'll try to make a version of the test that is unrandomized -- I'll index the
or just create a jira with...
* a patch
* the branch/revision you applied that patch to ("svnversion" output)
* cut/paste the failure stack trace & reproduce line that you get showing
the failing seed
* details o
Ok, thanks.
What I do in such circumstances is apply an aspect (aspectj) that logs
(for every thread) every entry/exit from a block of code I'm
interested in (package, class, etc.) and then run the two differing
configurations. Then I simply diff the outputs using Araxis Merge --
this is typically
I'll try to make a version of the test that is unrandomized -- I'll index the
exact shapes needed and query for the specific shape using the right
algorithm. And at that point, I'll try and reduce it. Simon's right; I'm
looking for debugging tips/strategy advise. I find it pretty odd that my
tes
I think david is just running into a situation were his test fail
sometimes with random seeds but always if he forces RAMDirectory no
matter what seed.
He is asking for advice if there are any traps with ram dir in
randomized testing...
maybe that helps
@David S.: why don't you paste a patch that
I still don't get what it is that you're after, David.
If you stumbled upon an execution path that (with a given seed)
reproduces the error you can isolate this path and create a test that
doesn't have any randomness anymore. If you only need it for temporary
debugging, pass -Dtests.seed and provi
I need a seed to ensure that my test, which uses a lot of randomization,
generates the right randomized shapes. This particular seed just so happens
to pick RAMDirectory as well, and that's how I first stumbled upon the
problem; all the circumstances were just right. I'm not manually using "new
R
> for the test to fail. If the *only* thing I change is
> -Dtests.directory=RAMDirectory then it fails absolutely every time at the
> same spot, and if the directory is something else because I set it with the
I don't think I follow you. RAMDirectory will be picked eventually
with some seed. What
Is it a particular seed that shows the failure with RAMDir?
If so, I think most likely by specifying the directory to ant you are
effectively altering the random seed?
If that's it, you can go into LuceneTestCase.java where it has this
directory logic and keep consuming the randomness but then ha
11 matches
Mail list logo
