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.

1 files changed, 3 insertions, 0 deletions

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"