4 ms·

If trying to solve a problem and errors keep occurring, how does one capture the errors (and inputs that caused the error) in order to blog about later without

by fm2606 2y ago

If trying to solve a problem and errors keep occurring, how does one capture the errors (and inputs that caused the error) in order to blog about later without disrupting the flow of problem solving? For example, I was writing a terraform script and I kept getting errors. I would change one thing, run plan and apply, get another error, rinse and repeat until I fixed it. I would like to keep a record of all these errors so that I can document it for my future self or colleagues, but I don't want to disrupt the process of trying to fix my problem. Does anyone have any suggestions? Thanks

wonger_ 2y ago
Personally, I keep a text file as a "debugging journal" and just append a line every time I try a new step. For example, this is what I wrote down after recently trying out a local LLM: llama.cpp - idk why there's so many llama versions to install on yay - i went with llama.cpp-bin, because it was built with libcurl and the first one i tried apparently was not - but i had to remove llama.cpp-git-debug from a previous installation - remember yay -Q | grep ... to check for installed packages - the cli interface changes; i ended up with --hf-repo ggml-org/qwen2.5... --hf-file qwen25.... - the huggingface.com page probably has the most accurate and up-to-date instructions - my goal: fast, offline, generalized/automatic autocomplete - localhost:8080 to access web ui after running llama-server They're quick notes, and they actually help me problem solve, not disrupt me. I'm casual about it, though. I'm not copying every input and output verbatim. I think the idea is to leave yourself enough breadcrumbs so that you can reproduce, grab screenshots, and copy error messages later when you're not in the zone. Hope this helps. Also, note that I'm most likely to publish a blog post in the following days while the problem is still fresh in my mind. If I wait months or years, it's pretty much doomed to stay in /drafts forever.
- fm2606 2y ago
  It does help, thank you. I was thinking that I'd just have to change my process a bit to capture what I need/want to document properly. For me, a few days might as well be a year in trying to remember :-(

by fm2606 2y ago

wonger_ 2y ago

Personally, I keep a text file as a "debugging journal" and just append a line every time I try a new step. For example, this is what I wrote down after recently trying out a local LLM: llama.cpp - idk why there's so many llama versions to install on yay - i went with llama.cpp-bin, because it was built with libcurl and the first one i tried apparently was not - but i had to remove llama.cpp-git-debug from a previous installation - remember yay -Q | grep ... to check for installed packages - the cli interface changes; i ended up with --hf-repo ggml-org/qwen2.5... --hf-file qwen25.... - the huggingface.com page probably has the most accurate and up-to-date instructions - my goal: fast, offline, generalized/automatic autocomplete - localhost:8080 to access web ui after running llama-server They're quick notes, and they actually help me problem solve, not disrupt me. I'm casual about it, though. I'm not copying every input and output verbatim. I think the idea is to leave yourself enough breadcrumbs so that you can reproduce, grab screenshots, and copy error messages later when you're not in the zone. Hope this helps. Also, note that I'm most likely to publish a blog post in the following days while the problem is still fresh in my mind. If I wait months or years, it's pretty much doomed to stay in /drafts forever.

fm2606 2y ago
It does help, thank you. I was thinking that I'd just have to change my process a bit to capture what I need/want to document properly. For me, a few days might as well be a year in trying to remember :-(