I could see some might dismiss this as noise, but I really like the idea of tracehash and it would be nice to see that catch on. (I think it would be interesting if it could be structured something like a geohash so truncation would reduce specificity, but it's less obvious how to do this here.) Since it takes up minimal space, I would be open to considering including it in stack traces.
-- Michael Mior mm...@apache.org Le ven. 26 avr. 2019 à 14:36, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> a écrit : > > Let me post a couple of links I've came across today (it comes out of this > Twitter thread: https://twitter.com/backendsecret/status/1121290210464034816 > ): > > https://github.com/alexknvl/fuzzball -- it is a machine learning driven > fuzzer for Scala which identifies quite a few bugs in Scala compiler. > > The beauty of ML is we don't need to somehow declare the grammar, but it > can just learn from lots of samples. > I've no idea if that would play well for SQL (we need to declare metadata > somehow), however it might still work somehow. > > Then there's https://github.com/cretz/javan-warty-pig a fuzzer + bytecode > agent to trace execution (it remembers the taken paths, so it distinguishes > "different" executions. > > https://github.com/alexknvl/tracehash -- a library that produces short > summaries for exception stacktraces. > Those signatures might be a good aid for "stackoverflow-guided-development" > (== we might want to print stacktrace signatures by default for Calcite > exceptions). > > Vladimir