8 ms·
Panicparse: Crash your Go app in style
- laumars 11y agoThis looks like it has real potential. I've lost count of the times I've had to scroll through a lengthy tmux buffer just to find the key 2 lines of the stack trace.
- nathancahill 11y agoSame with Python. I wonder if there's something similar.
- jonesb6 11y agoSeems like a great tool for wrangling Go's stack trace. Particularly relevant if you're running a large number of go routines since when they panic you'll console will blow up.
- vito 11y agoWrote a similar web-based tool a while back, primarily for grouping goroutines by their source location: https://github.com/vito/swirly https://github.com/vito/swirly Try it out here: https://rawgit.com/vito/swirly/master/index.html https://rawgit.com/vito/swirly/master/index.html ...with: https://gist.githubusercontent.com/vito/486918d4c759184eb1d4/raw/c3b1631ecf0a70afe18057102f95d00603473e4a/gistfile1.txt https://gist.githubusercontent.com/vito/486918d4c759184eb1d4...
- toqueteos 11y agoThis is even better! I highly encourage you to publish this or at least write a README for it.
- fiatjaf 11y agoWhy isn't the default panic like this?
- schmichael 11y agoBecause while far far denser and easier to parse by humans, it discards a considerable amount of data. I think it's perfectly sensible for the default toolchain to dump the most complete representation and allow users to use tools to get the representation they prefer.
- karaziox 11y agoBecause this one involve checking duplicates and does a fair amount of logic. When the process is crashing, all bets are off and you may not be able to allocate memory for this processing. This is why they simply dump all there is to stderr and exit.
- gamesbrainiac 11y agoThis is excellent. I wish I had this when I first started learning go. Will definitely recommend to new learners of the language.
- lsllc 11y agoWow, so much nicer -- works with SIGQUIT too. Very nice work!
- jacquesm 11y agoSomeone please pass this to the Go team, something like this would really be nice to have in the default Go distribution.
- scrollaway 11y agoOne thing I noticed the last time I worked with go was how hostile the go team was to stdlib changes and additions. Their default argument parsing library is pretty horrible - it uses single-dash for word flags (thus does not differenciate between -h -e -l -p and -help...) and they refuse to implement double-dash, citing "there's third party libs for that". It really annoys me. I understand the predicament that the stdlib should remain relatively stable, but setting the wrong example in the stdlib itself is really bad - third party libs or not, you know a fair share of people will stick to the stdlib where possible. I had the exact same experience with python a few days ago. Python's builtin elementtree can't add doctypes at all and is hostile to patches adding it. The reasoning being "lxml exists". For the simple task of adding a doctype, one must either deal with a cpython-specific extension that is a pain in the arse to build, or hack it in with undocumented functionality in minidom.
- soccerdave 11y agoThe lack of double-dash in the stdlib really annoys me. Almost all command line tools use a single dash for single letter arguments (-h) and double-dash for anything longer (--help).
- icholy 11y agodouble-dash still works.
- helper 11y agoI love that the go team is hostile to breaking stdlib changes (which is what changing the flag package would be). It is so nice to be able to upgrade to the latest go version without having to worry about what it might break in production. It is true that the go team is cautious about what goes into the stdlib. Part of that is their commitment to long term support of the standard library. To be able to do that effectively they need to be discerning when choosing what to have there vs an external library. But that doesn't mean that they don't take big changes. HTTP2 support will be in 1.6 which is a huge addition.
- jdoliner 11y agoGreat idea, would love to see this as a default part of the Go toolchain. I run in to this problem all the time.
- maleck13 11y agoThis looks great. Will definitely be making use of it
- f2f 11y agoto run it through its paces try giving it the goroutines output of a large server. https://http2.golang.org/goroutines https://http2.golang.org/goroutines is a good example. unfortunately its color palette is tailored to dark terminals: http://i.imgur.com/WqNVjfh.png http://i.imgur.com/WqNVjfh.png also unfortunate is that we've now lost path information and i can't just right-click to open the relevant line in the source. win some, lose some :)
- maruel 11y agoThanks for the comments! Filed two issues: Colors: https://github.com/maruel/panicparse/issues/11 https://github.com/maruel/panicparse/issues/11 Path: https://github.com/maruel/panicparse/issues/12 https://github.com/maruel/panicparse/issues/12
- hawski 11y agoSorry for such a pedantic comment for such a nice tool, but... I noticed that GIFs were attracting my attention, but were too for me to comprehend what was happening. They are not better than static text (you can color it if you want) or image. Is it common now to present screencasts instead of pasting text copied from for CLI tools?
- Gigablah 11y agoGIFs are much better in this context because the selling point of the tool is the workflow. Perhaps having GIF playback controls implemented in the browser would improve it. Correct me if I'm wrong, but you cannot have colored text in GitHub markdown. You can have syntax coloring, but in this case he's showing terminal output.
- dmit 11y agoSimilar tool for Rust: https://github.com/Ticki/dybuk https://github.com/Ticki/dybuk
- Aissen 11y agoJust tried it on old stacktraces I had lying around that I didn't analyze yet… And I think I just found a bug! Wow, thanks a lot @maruel !
- Aissen 11y agoPS: the bug is my fault. Never use _ to ignore errors. Never do it. Even when you think you've sanitized everything to death.