The second part of the seed is derived from the first (and iteration
number, test name etc) so typically the first would be sufficient.
D.
On Wed, Feb 5, 2020, 19:59 Michael Sokolov <msoko...@gmail.com> wrote:
> ah thanks I never did understand the split seed before. I'm still a
> little confused because I had previously thought that to reproduce a
> test failure I would define tests.seed= to be the first part of the
> seed (like it says in the repro line), but if I would still get a
> different seed applied to calls to random() within the test method,
> then I don't see how that works to make tests reproducible? Maybe I
> was just wrong, but it always seemed to work that way - I would often,
> usually, be able to repro random failures using only the first half of
> the seed.
>
> On Wed, Feb 5, 2020 at 1:27 PM Dawid Weiss <dawid.we...@gmail.com> wrote:
> >
> >
> > In case I was not clear: in case of most tests the tests.iters _is_ the
> right way to repeat the same test with different seeds. The only difference
> is when you would like to randomize static stuff - then tests.iters would
> still apply only to tests, not the static test context ( which would remain
> the same for all repetitions).
> >
> >
> > On Wed, Feb 5, 2020, 19:23 Dawid Weiss <dawid.we...@gmail.com> wrote:
> >>
> >>
> >> Short because I am on a phone only. The first part of the seed.is the
> "static" part that applies to static context - constructors, beforeclass
> etc. The second part would apply to methods. Test.iters is a.property
> recognized by the runner (so it works from the ide etc.) - if your random
> failure is at method level then the second part is relevant.
> >>
> >> Gradle build currently does not have "beasting" in the form of
> different static seeds. This would have to be implemented as a series of
> recursive calls with different master seeds...
> >> Complicated but not impossible.
> >>
> >>
> >>
> >> On Wed, Feb 5, 2020, 18:49 Michael Sokolov <msoko...@gmail.com> wrote:
> >>>
> >>> Hi, I've been using gradlew a lot last few days, and first I want to
> >>> give a huge thanks to those who did the work to make this possible.
> >>> I'm not naming names since I probably don't know everyone who chipped
> >>> in, but this is really great. I'm especially loving the `gradlew
> >>> tasks` and the excellent documentation for the tasks!
> >>>
> >>> Now my beasting beef :) I did some beasting and got a bunch of
> >>> failures, and it looks as if they were all run with the same seed;; eg
> >>> here's some output from the test showing (I think) two failures with
> >>> the same seed. I had 43 failures out of 1400, all with the same (first
> >>> part of) the random seed
> >>>
> >>> -
> org.apache.lucene.search.TestTopFieldCollector.testRandomMaxScoreTermination
> >>> {seed=[C95A2DAEAA6E2219:1FAD1846BF530502]} (:lucene:core)
> >>> Test output:
> >>> /home/
> ANT.AMAZON.COM/sokolovm/workspace/lucene-solr/lucene/core/build/test-results/test/outputs/OUTPUT-org.apache.lucene.search.TestTopFieldCollector.txt
> >>> Reproduce with: gradlew :lucene:core:test --tests
> >>> "org.apache.lucene.search.TestTopFieldCollector"
> >>> -Ptests.seed=C95A2DAEAA6E2219 -Ptests.iters=100
> >>> -Ptests.file.encoding=US-ASCII
> >>>
> >>> -
> org.apache.lucene.search.TestTopFieldCollector.testRandomMaxScoreTermination
> >>> {seed=[C95A2DAEAA6E2219:11046F532841C712]} (:lucene:core)
> >>> Test output:
> >>> /home/
> ANT.AMAZON.COM/sokolovm/workspace/lucene-solr/lucene/core/build/test-results/test/outputs/OUTPUT-org.apache.lucene.search.TestTopFieldCollector.txt
> >>> Reproduce with: gradlew :lucene:core:test --tests
> >>> "org.apache.lucene.search.TestTopFieldCollector"
> >>> -Ptests.seed=C95A2DAEAA6E2219 -Ptests.iters=100
> >>> -Ptests.file.encoding=US-ASCII
> >>>
> >>>
> >>> I tried poking around in randomization.gradle to see if I could verify
> >>> and/or fix, but I'm not sure how the tests.iters mechanism works - is
> >>> it built into gradle? Something we added on top?
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
