Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | 1187 | Kartik K. Agaram | 2015-04-24 | 2 | -2/+62 |
| | |||||
* | 1186 | Kartik K. Agaram | 2015-04-24 | 2 | -3/+0 |
| | |||||
* | 1185 - inline C++ in scenarios | Kartik K. Agaram | 2015-04-24 | 5 | -23/+9 |
| | |||||
* | 1184 - finally, concurrency | Kartik K. Agaram | 2015-04-24 | 119 | -65/+229 |
| | |||||
* | 1183 | Kartik K. Agaram | 2015-04-24 | 4 | -0/+7 |
| | |||||
* | 1182 | Kartik K. Agaram | 2015-04-24 | 2 | -9/+0 |
| | |||||
* | 1181 | Kartik K. Agaram | 2015-04-24 | 2 | -6/+4 |
| | | | | Purge unordered_* from subdirectories as well. | ||||
* | 1180 - finally dump that 'pc' reference | Kartik K. Agaram | 2015-04-24 | 2 | -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. | ||||
* | 1179 | Kartik K. Agaram | 2015-04-24 | 2 | -9/+6 |
| | |||||
* | 1178 | Kartik K. Agaram | 2015-04-24 | 1 | -3/+2 |
| | |||||
* | 1177 | Kartik K. Agaram | 2015-04-24 | 4 | -7/+7 |
| | |||||
* | 1176 | Kartik K. Agaram | 2015-04-24 | 3 | -9/+9 |
| | |||||
* | 1175 | Kartik K. Agaram | 2015-04-24 | 2 | -8/+0 |
| | |||||
* | 1174 | Kartik K. Agaram | 2015-04-24 | 1 | -1/+1 |
| | |||||
* | 1173 | Kartik K. Agaram | 2015-04-24 | 2 | -4/+4 |
| | |||||
* | 1172 | Kartik K. Agaram | 2015-04-24 | 2 | -11/+11 |
| | |||||
* | 1171 | Kartik K. Agaram | 2015-04-24 | 16 | -155/+162 |
| | | | | | Chip away at eliminating that 'pc' reference by first throwing out the most common expression that uses it: instructions[pc]. | ||||
* | 1170 | Kartik K. Agaram | 2015-04-24 | 3 | -8/+10 |
| | |||||
* | 1169 - use the global variable god gave you | Kartik K. Agaram | 2015-04-24 | 5 | -53/+56 |
| | |||||
* | 1168 | Kartik K. Agaram | 2015-04-24 | 14 | -76/+76 |
| | |||||
* | 1167 | Kartik K. Agaram | 2015-04-24 | 1 | -1/+1 |
| | |||||
* | 1166 | Kartik K. Agaram | 2015-04-24 | 14 | -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. | ||||
* | 1165 | Kartik K. Agaram | 2015-04-24 | 1 | -2/+2 |
| | |||||
* | 1164 | Kartik K. Agaram | 2015-04-24 | 1 | -0/+3 |
| | |||||
* | 1163 | Kartik K. Agaram | 2015-04-24 | 4 | -11/+11 |
| | |||||
* | 1162 | Kartik K. Agaram | 2015-04-24 | 23 | -99/+99 |
| | |||||
* | 1161 | Kartik K. Agaram | 2015-04-24 | 1 | -1/+1 |
| | |||||
* | 1160 | Kartik K. Agaram | 2015-04-24 | 1 | -1/+1 |
| | |||||
* | 1159 | Kartik K. Agaram | 2015-04-24 | 2 | -2/+2 |
| | |||||
* | 1158 | Kartik K. Agaram | 2015-04-24 | 1 | -14/+15 |
| | |||||
* | 1157 | Kartik K. Agaram | 2015-04-24 | 1 | -3/+3 |
| | |||||
* | 1156 | Kartik K. Agaram | 2015-04-24 | 1 | -1/+1 |
| | |||||
* | 1155 - three phases of mu: load, transform, run | Kartik K. Agaram | 2015-04-24 | 7 | -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. | ||||
* | 1154 | Kartik K. Agaram | 2015-04-24 | 1 | -1/+1 |
| | |||||
* | 1153 - start of scheduler implementation | Kartik K. Agaram | 2015-04-23 | 2 | -2/+23 |
| | | | | | This first step is just stopping run() after a fixed number of instructions. But the scheduler layer isn't done yet. | ||||
* | 1152 | Kartik K. Agaram | 2015-04-23 | 1 | -7/+0 |
| | |||||
* | 1151 | Kartik K. Agaram | 2015-04-23 | 3 | -10/+32 |
| | |||||
* | 1150 | Kartik K. Agaram | 2015-04-23 | 1 | -1/+0 |
| | |||||
* | 1149 | Kartik K. Agaram | 2015-04-23 | 1 | -0/+7 |
| | |||||
* | 1148 - valgrind ALL the things! | Kartik K. Agaram | 2015-04-22 | 2 | -2/+5 |
| | |||||
* | 1147 - one final memory leak; now valgrind-clean | Kartik K. Agaram | 2015-04-22 | 1 | -1/+0 |
| | |||||
* | 1146 - yet another out-of-bounds access | Kartik K. Agaram | 2015-04-22 | 3 | -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 support | Kartik K. Agaram | 2015-04-22 | 2 | -118/+14 |
| | |||||
* | 1144 - dump termbox's support for modifier keys | Kartik K. Agaram | 2015-04-22 | 3 | -60/+9 |
| | |||||
* | 1143 | Kartik K. Agaram | 2015-04-22 | 2 | -1/+1 |
| | |||||
* | 1142 | Kartik K. Agaram | 2015-04-22 | 4 | -181/+159 |
| | |||||
* | 1141 | Kartik K. Agaram | 2015-04-22 | 1 | -25/+18 |
| | |||||
* | 1140 | Kartik K. Agaram | 2015-04-22 | 2 | -42/+0 |
| | | | | Dump deprecated interface. | ||||
* | 1139 | Kartik K. Agaram | 2015-04-22 | 6 | -864/+864 |
| | | | | Reindent termbox. | ||||
* | 1138 - fix some termbox warnings | Kartik K. Agaram | 2015-04-22 | 2 | -3/+7 |
| |