We want to run with a heap big enough, otherwise we just do garbage collection...

We'll look into /usr/local/ first.

If it now works, it will be the end of years of struggle to get these
damn library.path set!

Instead of trying to manipulate tasks directly, the plugin just sets
and extra property you should have access to.

If the user had PAPI_LIBRARY_PATH set, then we add it to the list of options.

We move setting the java.library.path for brainy executables in the
main build.gradle, inside a plugin.

That way, we don't need to configure the sub-projects.

The function loadSeeds() is called during configuration, not when the
task is executed. Therefore, if the file containing the seeds does not
exist, ALL the other tasks would fail. We use that to prevent that.

We don't need UNIFORM for now.

We can read the command-line arguments from STDIN instead of the args
array. That should be helpful when we want to load a lot of seeds to
benchmark in a row!

We can read the command-line arguments from STDIN instead of the args
array. That should be helpful when we want to load a lot of seeds to
benchmark in a row!

Loading from a big file was too slow, hopefully this makes it faster

We use the file "seeds-benchmarks.csv" to load the data for the seeds
we'd want to try, we use the function loadSeeds to convert that to
arguments JMH can take, then we pass that as arguments to the runner.

(That can be a looot of arguments for some cases, I wonder if it can
take all these arguments)

We run it 30 times instead of 10.

The SeedSampler generates new seeds, we allow a threshold for the number
of seeds set. The tool will stop when it reaches that threshold.

We renamed the argument in a previous commit.

Added a gradle task that runs an experiment where different generation
schemes are used to generate benchmarks. We want to compare them.

Renamed the argument "number seeds" into "target size" since it's the
number of benchmarks we want to each interface.

That argument changes the number of times each benchmark is run (more
times gives a more precise estimate, but takes less time).

This is used to find a set of seeds that exercises each collections'
strengths and weaknesses.

We changed to a sequence of benchmarks that fit better our current use
case.

We use the parameters that were used in the Brainy study, cause we want
to "reproduce" their work.

We only generate markov benchmarks now because they give the best
accuracy when training the classifier.

When a JMH task run, we print STDOUT to log files, so that we don't lose
the output if some other program writes to the output afterwards.

You can run benchmarks with the collection filled with random values
from the start, but we disabled that, it was buggy and we were unsure
it was actually necessary.

This subproject is about JMH evaluation of benchmarks built with
existing software traces.

Re-implemented a way similar as the way used for the
JMH plugin, so that the options for benchmarking are in
the build script.

/Finally/ managed to implement my own!

The build scripts is split in two parts, one for each subprojects

There were quite a few things wrong with the build script (remnants of
build scripts for older versions of gradle)

Trying to make the `jmhJar` task work.

Changed build scripts to run small benchmarks instead of the
big ones for experiments