Instead of setup() and teardown() we'll just use a reset() function from
now on, which will bring the machine back to a good state before each
test or run, and also before exit (to avoid memory leaks).
I've been putting up for some time with the tension between wanting to
show scenarios at the top of the layer even if I want to *run* any unit
tests of sub-components introduced within the layer before them. Turned
out to be an easy fix.
We don't have very many of these, and the unit tests in the early layers
don't compete with any scenarios, so I don't need to mess with them. But
this is a key tool in my toolkit, to be able to decouple presentation
order from run order for tests.
Though now the separate compilation units are again unbalanced; sigh.
Undo 3272. The trouble with creating a new section for constants is that
there's no good place to order it since constants can be initialized
using globals as well as vice versa. And I don't want to add constraints
disallowing either side.
Instead, a new plan: always declare constants in the Globals section
using 'extern const' rather than just 'const', since otherwise constants
implicitly have internal linkage (http://stackoverflow.com/questions/14894698/why-does-extern-const-int-n-not-work-as-expected)
Move global constants into their own section since we seem to be having
trouble linking in 'extern const' variables when manually cleaving mu.cc
into separate compilation units.
Clean up the Globals section so that we can generate extern declarations
for all globals out using this command after we carve it out into
globals.cc:
grep ';' globals.cc |perl -pwe 's/[=(].*/;/' |perl -pwe 's/^[^\/# ]/extern $&/' > globals.h
The first perl command strips out initializers. The second prepends
'extern'. This simplistic approach requires each global definition to
lie all on one line.
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.)
Kartik Agaram