From 8f2496770dcf1160a2150acd73a3d082298b4d06 Mon Sep 17 00:00:00 2001 From: "Kartik K. Agaram" Date: Sun, 29 Nov 2015 12:42:04 -0800 Subject: 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.) --- 000organization.cc | 1 + 1 file changed, 1 insertion(+) (limited to '000organization.cc') diff --git a/000organization.cc b/000organization.cc index 61c60b63..0f2518f5 100644 --- a/000organization.cc +++ b/000organization.cc @@ -105,6 +105,7 @@ int main(int argc, char* argv[]) { // End One-time Setup + // Commandline Parsing // End Commandline Parsing return 0; // End Main -- cgit 1.4.1-2-gfad0