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 |
| | |||||
* | 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 |
| |