- User Since
- Oct 3 2012, 4:55 AM (341 w, 3 d)
Thu, Apr 18
Wed, Apr 17
sorry for delay.
Vitaly, can you give a recommendation on how to avoid #ifdefs and avoid too much code duplication in this case.
Fri, Apr 12
Code LGTM, but please also add a test that would fail with current code and pass with your change.
Either extend test/fuzzer/dataflow.test or add another one nearby.
Thu, Apr 11
Wed, Apr 10
I don't think this is right. This subprocess is *expected* to fail with exactly this message when we run out of labels,
and then we handle the input as two subsets, and so on.
But this error must not happen if the range is >= 2 (two labels should not cause this error), so the process converges.
We can not predict when we run out of labels -- for some 8k inputs it will work from the first attempt,
for some much smaller inputs it will require several bisections.
Mon, Apr 8
Hm... But this is so much code duplication... Can we have few #ifdefs but also not too much duplication?
Fri, Apr 5
Please don't use this many #ifdefs.
If should not need more than one ifdef for this patch,
Split the logic into separate files, when needed.
Mar 18 2019
Mar 11 2019
Feb 28 2019
- I am not sure what problem does it solve. Everything seems to work.
- We can now safely remove fuzzer_allocator and rename Vector to just plain std::vector. (we don't need this monstrosity any more since we are using private STL now)
Feb 27 2019
Reid has a good point, and it equally applies to the current code, which doesn't instrument unreachable blocks.
Feb 25 2019
Feb 21 2019
Test change LGTM.
I don't know much about Windows, so will rely on Zach's os someone else's review.
Feb 20 2019
Feb 19 2019
Feb 15 2019
Feb 14 2019
Feb 13 2019
and welcome back to the project! :)
Feb 12 2019
Feb 11 2019