about summary refs log tree commit diff stats
path: root/cpp
Commit message (Collapse)AuthorAgeFilesLines
* 1187Kartik K. Agaram2015-04-242-2/+62
|
* 1186Kartik K. Agaram2015-04-242-3/+0
|
* 1185 - inline C++ in scenariosKartik K. Agaram2015-04-245-23/+9
|
* 1184 - finally, concurrencyKartik K. Agaram2015-04-24119-65/+229
|
* 1183Kartik K. Agaram2015-04-244-0/+7
|
* 1182Kartik K. Agaram2015-04-242-9/+0
|
* 1181Kartik K. Agaram2015-04-242-6/+4
| | | | Purge unordered_* from subdirectories as well.
* 1180 - finally dump that 'pc' referenceKartik K. Agaram2015-04-242-4/+2
| | | | | | In the process we uncovered yet another out-of-bounds access, in the implementation of 'reply'. Another sign from the gods that large-scope pointers/references are a bad idea.
* 1179Kartik K. Agaram2015-04-242-9/+6
|
* 1178Kartik K. Agaram2015-04-241-3/+2
|
* 1177Kartik K. Agaram2015-04-244-7/+7
|
* 1176Kartik K. Agaram2015-04-243-9/+9
|
* 1175Kartik K. Agaram2015-04-242-8/+0
|
* 1174Kartik K. Agaram2015-04-241-1/+1
|
* 1173Kartik K. Agaram2015-04-242-4/+4
|
* 1172Kartik K. Agaram2015-04-242-11/+11
|
* 1171Kartik K. Agaram2015-04-2416-155/+162
| | | | | Chip away at eliminating that 'pc' reference by first throwing out the most common expression that uses it: instructions[pc].
* 1170Kartik K. Agaram2015-04-243-8/+10
|
* 1169 - use the global variable god gave youKartik K. Agaram2015-04-245-53/+56
|
* 1168Kartik K. Agaram2015-04-2414-76/+76
|
* 1167Kartik K. Agaram2015-04-241-1/+1
|
* 1166Kartik K. Agaram2015-04-2414-46/+41
| | | | | | | Why did I think STL's map wasn't efficient? It has logarithmic complexity (maintains a tree internally) and is faster than hashing for small containers. It's the more portable solution and should be what I turn to by default.
* 1165Kartik K. Agaram2015-04-241-2/+2
|
* 1164Kartik K. Agaram2015-04-241-0/+3
|
* 1163Kartik K. Agaram2015-04-244-11/+11
|
* 1162Kartik K. Agaram2015-04-2423-99/+99
|
* 1161Kartik K. Agaram2015-04-241-1/+1
|
* 1160Kartik K. Agaram2015-04-241-1/+1
|
* 1159Kartik K. Agaram2015-04-242-2/+2
|
* 1158Kartik K. Agaram2015-04-241-14/+15
|
* 1157Kartik K. Agaram2015-04-241-3/+3
|
* 1156Kartik K. Agaram2015-04-241-1/+1
|
* 1155 - three phases of mu: load, transform, runKartik K. Agaram2015-04-247-22/+18
| | | | | | Each phase implicitly calls previous phases. Most C++ scenarios implicitly call one, two or three of the phases. More clear now that 'load' does more than just add recipes.
* 1154Kartik K. Agaram2015-04-241-1/+1
|
* 1153 - start of scheduler implementationKartik K. Agaram2015-04-232-2/+23
| | | | | This first step is just stopping run() after a fixed number of instructions. But the scheduler layer isn't done yet.
* 1152Kartik K. Agaram2015-04-231-7/+0
|
* 1151Kartik K. Agaram2015-04-233-10/+32
|
* 1149Kartik K. Agaram2015-04-231-0/+7
|
* 1148 - valgrind ALL the things!Kartik K. Agaram2015-04-222-2/+5
|
* 1147 - one final memory leak; now valgrind-cleanKartik K. Agaram2015-04-221-1/+0
|
* 1146 - yet another out-of-bounds accessKartik K. Agaram2015-04-223-2/+66
| | | | | | | | | | | | | | There's a test in this commit, but it doesn't actually fail, because by some accident the memory at index 2 of recipe 'f' has data at the is_label offset and breaks out of the loop. Graah. How did I ever misplace that "Reading One Instruction" waypoint? I could swear I was concerned about this possibility when I implemented calls. Today has been tough on my confidence. STL helps avoid memory leaks but doesn't help with buffer overflows nearly as much as I thought. Oh brilliant, valgrind caught the problem! And there weren't any others. I feel much better.
* 1145 - dump termbox's 256-color supportKartik K. Agaram2015-04-222-118/+14
|
* 1144 - dump termbox's support for modifier keysKartik K. Agaram2015-04-223-60/+9
|
* 1143Kartik K. Agaram2015-04-222-1/+1
|
* 1142Kartik K. Agaram2015-04-224-181/+159
|
* 1141Kartik K. Agaram2015-04-221-25/+18
|
* 1140Kartik K. Agaram2015-04-222-42/+0
| | | | Dump deprecated interface.
* 1139Kartik K. Agaram2015-04-226-864/+864
| | | | Reindent termbox.
* 1138 - fix some termbox warningsKartik K. Agaram2015-04-222-3/+7
|
* 1137Kartik K. Agaram2015-04-221-5/+5
|