Unleash the treefrog

[lqd]

It could be time, for the 🐸 to leap from its tree and join us.
Worst case, that leap is optimal!

:)

[nikomatsakis]

Code looks good to me! I took the liberty of pushing some additional cargo fmt + travis etc stuff into this PR, plus a rebase or two.

[frankmcsherry]

👍

[frankmcsherry]

Do you have merge rights, or should I click the big "merge pull request" button for you?

[nikomatsakis]

I have merge rights; I was going to let travis finish.

[nikomatsakis]

@frankmcsherry btw have you given any thought to how to do automated testing? I was contemplating trying to generate random data and some kind of "mega naive merge" algorithm and use that to create unit tests of the various join combinators.

[nikomatsakis]

Possible mega naive join would be something like:

let mut join = source1.clone();
join.extend(source2.clone());
join.sort();
join.dedup();

[frankmcsherry]

I have given it thought, and not come up with anything especially good. At least, over in more general "differential" space, I've not had great ideas about how to cover the sketchy cases with confidence. What I've done over there is try to do something like Graydon's philosophy that when you land commits you also put in tests that break before but not afterwards. These were more perf-oriented than correctness, though. =/

[nikomatsakis]

OK. I figured I'd start off with a base of various "smoke tests" that use random data like I suggested, and then we'd add regression tests for specific bugs that are found (as you suggest).

[frankmcsherry]

That seems sane. One should be able to write fuzzing tests with random data, I'd bet, relating e.g. treefrog, naive datafrog, and brute-force, but I'm not sure about the confidence (e.g. would cover random data, but not random queries which are more strongly bound to the code itself).

[nikomatsakis]

Indeed. I opened #15 for further discussion.