It would be interesting if the Tracehash author had a source of bug reports identified as duplicates along with stack traces to see how well it works in practice. At this point, it seems like it's just a heuristic based on an opinion of what's important. -- Michael Mior [email protected]
Le ven. 26 avr. 2019 à 15:10, Michael Mior <[email protected]> a écrit : > > 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 > [email protected] > > Le ven. 26 avr. 2019 à 14:36, Vladimir Sitnikov > <[email protected]> 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
