--- Day changed Fri Sep 07 2018
11:36 < Blackwolfsa> Yeah no, the client should never be forced to implement stuff for some absurdly rare conditions.  But if we can incorporate everything into a single error-handler , we can easily incorporate a "small blanket" to cover those and we dont let the thread free fall.  And if all errors work from a single error handler it should be trivial or close to that to solver (b).
13:53 < BlueMatt> Blackwolfsa: hmm, yea, I mean I think we kinda mostly agree here, but are just debating whether or not it'd look clean.....given the early stage of things I'm obviously very open to large-scale refactors no problem, so if you want to explore a bit and see what you can come up with maybe that would make the discussion more concrete
18:35 < andytoshi> lol 838 files changed by 166
18:35 < andytoshi> how do i even review that
18:42 < BlueMatt> lol you dont
18:42 < BlueMatt> I mean review the AFL bump
18:43 < BlueMatt> for the first one you can load up honggfuzz and see if the edge numbers go up after the initial dry run
18:43 < BlueMatt> that would tell you that coverage of the things being tested increased
18:43 < BlueMatt> for each fuzz_target, that is
18:43 < BlueMatt> I mean even if the inputs are garbage its not really that bad, just will take someone else running a fuzzer a bit of time to get back to sanity
18:56 < andytoshi> yeah, i mean i still have to run `git diff --stat` and scroll through the list of files to see that none of them are sourcecode
18:56 < andytoshi> and even that will be a chore for 800 lines :P
18:58 < andytoshi> oh, no, it was easy, i just scrolled through and checked that all the lines started the same
19:02 < BlueMatt> lol, thats what search is for :p
19:02 < BlueMatt> git show --stat .. /.rs
19:02 < andytoshi> oh, nice trick
21:44 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 260 seconds]