diff options
author | Kartik K. Agaram <vc@akkartik.com> | 2015-11-29 12:42:04 -0800 |
---|---|---|
committer | Kartik K. Agaram <vc@akkartik.com> | 2015-11-29 12:42:04 -0800 |
commit | 8f2496770dcf1160a2150acd73a3d082298b4d06 (patch) | |
tree | fb2e9fc554910103127dee74083270315f98f4b6 /html/edit | |
parent | 81c87f08fa4fd9a27908b1d92c8aa897ad20cbb8 (diff) | |
download | mu-8f2496770dcf1160a2150acd73a3d082298b4d06.tar.gz |
2609 - run $browse-trace on old runs
This is long overdue. Let's see if it gets me using traces more during debugging. Though perhaps I'm being too persnickety. These are all valid ways to debug programs: a) print directly to screen b) log, and then dump the log on some condition c) temporarily print selected log statements directly to screen d) log, and then browse the log using the zoom interface For a) to work we need to normally keep prints empty. For b) to work the log needs to be of some manageable size, where it's tractable to find interesting features. d) is the ultimate weapon, but might be slow because it's interactive c) seems like the ugly case. Should I be trying to avoid it altogether? Let's try, and see if d) is useable when we want to do c). For simple cases it's still totally acceptable to just print. If the prints get too complex to parse, then we move to the zoom interface. Hopefully it'll be easier because we have to spend less time getting the prints just so. (Independent of all this, often the best way to make a log manageable so any of the approaches works: distill the bad behavior down to a test. But that leads to chicken-and-egg situations where you need to first understand before you can distill.)
Diffstat (limited to 'html/edit')
0 files changed, 0 insertions, 0 deletions