From 8359e5798993b4c2d2b5da7b03b38ead5c0f32ca Mon Sep 17 00:00:00 2001 From: Kartik Agaram Date: Sun, 3 Mar 2019 11:02:11 -0800 Subject: 4994 Bring back support for incrementally printing the trace to the screen (stderr). I previously thought I didn't need this as long as I'm always incrementally saving to the 'last_run' trace file. But I quickly ran into a use for it: when I want to see a complete trace including switching into the sandbox's trace and back out again. So there are now two separate commandline flags: --trace to save the trace to file --dump to print the trace to screen The former won't handle sandbox traces. But the latter will. I'm deemphasizing --dump in the help message since it should be rarely used. One other situation where I've used stderr in the past is for just raw convenience. But trying to always use the trace was a foolish consistency. Conclusion: a) For simple debugging, feel free to just use cout/cerr. Delete them before committing. b) If the prints get too complex, switch to the trace and browse_trace tool. c) If using nested sandboxes, emit to stderr, redirect to file, and browse_trace. I've gone back and forth on these questions in the past; now I'm trying to be a little more rigorous about capturing reasoning. --- 001help.cc | 3 +++ 1 file changed, 3 insertions(+) (limited to '001help.cc') diff --git a/001help.cc b/001help.cc index 3cab06d9..78877561 100644 --- a/001help.cc +++ b/001help.cc @@ -39,6 +39,9 @@ if (argc <= 1 || is_equal(argv[1], "--help")) { << " To see where a mu program is spending its time:\n" << " mu --profile file_or_dir1 file_or_dir2 ...\n" << " this slices and dices time spent in various profile.* output files\n" + << " To print out the trace to stderr:\n" + << " mu --dump file1.mu file2.mu ...\n" + << " this is handy when you want to see sandboxed traces alongside the main one\n" << "\n" << " To browse a trace generated by a previous run:\n" << " mu browse-trace file\n" -- cgit 1.4.1-2-gfad0