about summary refs log tree commit diff stats
path: root/chessboard.mu
Commit message (Collapse)AuthorAgeFilesLines
...
* 479Kartik K. Agaram2015-01-021-125/+19
|
* 478 - snapshot while debugging chessboardKartik K. Agaram2015-01-011-19/+126
| | | | | | | | | | | | | | | | | | | | | | This took a couple of hours to track down. I had to shrink down to a 2x2 chessboard, isolate a half-move (just a square to clear) that triggered an error, then hard-code the half-move to make it non-interactive, then copy my changes over to the non-cursor version in chessboard.mu, then start debugging trace. And then I found I was using an 'index-address' rather than 'index' to go from a board to a file-address inside 'make-move'. And that was corrupting the array of file pointers. Things I wish I had to help me here: a) a type checker. b) more speed. Are lists slowing down super-linearly? need an arc profiler. c) a side channel for traces even when the program is in cursor mode. I do have that (hence the 'new-trace' before calling main), but for some reason it wasn't convenient. Just had to buckle down, I think. d) the right '#ifdef's to switch between hard-coded move and interactive move, text vs cursor mode, etc. e) just in general better curation of traces to easily see what's going on. But that's just a pipe dream.
* 473 - print chessboardKartik K. Agaram2014-12-311-9/+32
| | | | | | | | Once we started printing we uncovered that we were storing positions by rank rather than by file as we'd planned. Amazing how slow it is. Might be interesting to try to compile it down to straightforward assembler and see how fast it gets.
* 472Kartik K. Agaram2014-12-301-6/+41
|
* 471 - experiment: chessboard appKartik K. Agaram2014-12-301-0/+25
No tests. Let's have some fun. As a first step, a 'list-length' function. Iterative version is 25% faster than recursive (60 vs 45 seconds).