about summary refs log tree commit diff stats
path: root/000organization.cc
Commit message (Collapse)AuthorAgeFilesLines
* 3557Kartik K. Agaram2016-10-221-4/+4
|
* 3414Kartik K. Agaram2016-09-241-1/+1
|
* 3297 - run unit tests before scenariosKartik K. Agaram2016-09-051-0/+3
| | | | | | | | | | | | | | 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.
* 3273Kartik K. Agaram2016-08-281-7/+9
| | | | | | | | | | | 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)
* 3272Kartik K. Agaram2016-08-281-0/+3
| | | | | | 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.
* 3270Kartik K. Agaram2016-08-281-0/+5
| | | | | | | | | | | | 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.
* 3027Kartik K. Agaram2016-06-021-1/+1
|
* 2935Kartik K. Agaram2016-05-071-2/+2
|
* 2609 - run $browse-trace on old runsKartik K. Agaram2015-11-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.)
* 1342Kartik K. Agaram2015-05-111-8/+8
|
* 1330Kartik K. Agaram2015-05-101-0/+5
|
* 1294Kartik K. Agaram2015-05-061-5/+5
|
* 1276 - make C++ version the defaultKartik K. Agaram2015-05-051-0/+121
I've tried to update the Readme, but there are at least a couple of issues.