Hello.
>>>[...]
> > If the user forgets to supply one, the program outputs one, and stops;
> > then the user reissues the command?
>
> Yes:
>
> > java -jar examples-stress.jar -h
>
> Print something helpful
>
> > java -jar examples-stress.jar --template
>
> Print a template generators list to stdout
>
> > java -jar examples-stress.jar --template > list.txt
>
> > java -jar examples-stress.jar target/tu_ 4 list.txt BE
> ./stdin2testu01 BigCrush
>
>
> I've used picocli before. It definitely needs very little extra code due
> to the use of annotations.
>
> One thing I do not know is what happens to the arguments for the stress
> test program, e.g.
>
> /usr/bin/dieharder -a -g 200 -Y 1 -k 2
>
> If they match anything used by the examples-stress.jar program then they
> will be consumed by a parser. If options match arguments to be passed to
> the stress test program then the executable program would have to be put
> into a script. For now we can choose the arguments to not clash. Should
> be simple given we avoid these:
>
> ./stdin2testu01 BigCrush
>
> /usr/bin/dieharder -a -g 200 -Y 1 -k 2
>
> So:
>
> -h, --help => help
>
> --template => print a template
>
> I would leave these as mandatory as they are all important to not forget:
>
> * output file prefix
> * int threads
> * generators list
> * endianness (an enum of BE or LE)
> * application
> * application arguments
>
> For picocli that would be:
>
> @Parameters(index = "0") File prefix;
> @Parameters(index = "1") int threadCount;
> @Parameters(index = "2") File generatorsList;
> @Parameters(index = "3") Endianness endianness;
> @Parameters(index = "4") File executable;
> @Parameters(index = "5..*") String[] executableArguments;
>
>
> So it is very simple. I will make modifications to the updated program
> to use Picocli.
I'd suggest to change the program usage to make it more flexible, i.e.
$ java -jar RandomStressTester.jar --prefix prefix --threads 4 --tasks
genlist --byteorder BE -- /usr/bin/dieharder -a -g 200 -Y 1 -k 2
Thus, everything tha follows the double-dash is the command-line
for the "ProcessBuilder".
And there can be default values for
* prefix (possibly aborting if the targets already exist)
* threads
* tasks (a file provided in the JAR (?))
* byteorder ("LE")
So, this could work too:
$ java -jar RandomStressTester.jar -- /usr/bin/dieharder -a -g 200 -Y 1 -k 2
>
> For reference here are the results of BigCrush with:
>
> The correct little-endian byte order:
>
> XorShiftXorComposite : 54, 53, 53 : 646.8 +/- 10.9
> XorShiftSerialComposite : 40, 39, 39 : 608.2 +/- 3.9
> SplitXorComposite : 0, 0, 0 : 625.8 +/- 0.2
>
> The incorrect big-endian byte order:
>
> XorShiftXorComposite : 92, 89, 90 : 986.7 +/- 4.3
> XorShiftSerialComposite : 75, 74, 76 : 632.0 +/- 2.3
>
> (I did not run the control.)
>
> This makes a fair bit of difference as it did for dieharder. So the byte
> order is important to get correct. I.e. you are not testing the true
> output of the generator if the bytes are reversed.
I wonder whether this is the consequence of correlations.
IOW: Would order matter for a good generator?
Regards,
Gilles
>
> Alex
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
