| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | 1196 | Kartik K. Agaram | 2015-04-24 | 2 | -1/+1 |
| | | |||||
| * | 1195 | Kartik K. Agaram | 2015-04-24 | 2 | -0/+41 |
| | | |||||
| * | 1194 | Kartik K. Agaram | 2015-04-24 | 103 | -1/+107 |
| | | |||||
| * | 1193 | Kartik K. Agaram | 2015-04-24 | 16 | -80/+94 |
| | | |||||
| * | 1192 | Kartik K. Agaram | 2015-04-24 | 2 | -19/+18 |
| | | |||||
| * | 1191 | Kartik K. Agaram | 2015-04-24 | 1 | -1/+2 |
| | | |||||
| * | 1190 | Kartik K. Agaram | 2015-04-24 | 1 | -7/+4 |
| | | |||||
| * | 1189 - add extensions to all layers | Kartik K. Agaram | 2015-04-24 | 36 | -3/+0 |
| | | | | | | | I'm sick of fighting vim's filetype detection. No modeline and files highlight in random colors. I add a modeline and it stops highlighting tangle comments. Even though it read my #$%# vimrc! Fuck this shite. | ||||
| * | 1188 | Kartik K. Agaram | 2015-04-24 | 2 | -6/+6 |
| | | |||||
| * | 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 |
| | | |||||
| * | 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. | ||||