Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | 1225 | Kartik K. Agaram | 2015-04-29 | 1 | -0/+6 |
| | | | | Finally start tracing the actual instructions as they run. | ||||
* | 1223 - more stable traces for parse scenarios | Kartik K. Agaram | 2015-04-29 | 1 | -6/+6 |
| | |||||
* | 1194 | Kartik K. Agaram | 2015-04-24 | 1 | -0/+1 |
| | |||||
* | 1184 - finally, concurrency | Kartik K. Agaram | 2015-04-24 | 1 | -0/+1 |
| | |||||
* | 1166 | Kartik K. Agaram | 2015-04-24 | 1 | -3/+3 |
| | | | | | | | 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. | ||||
* | 1146 - yet another out-of-bounds access | Kartik K. Agaram | 2015-04-22 | 1 | -0/+40 |
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. |