about summary refs log tree commit diff stats
path: root/chessboard.mu
Commit message (Collapse)AuthorAgeFilesLines
* 1119 - preparing to start porting chessboardKartik K. Agaram2015-04-211-18/+21
| | | | | | | | | Arc version is 15% faster (8.3s vs 9.9s for print-board test) if I use an intermediate array rather than list. I'm starting to question the whole tagged-value design, and the current tagged-value implementation was treating squares as integers in one place anyway, so its benefits for typing are not great. Might as well create a good baseline for the Arc vs C++ performance test.
* 893 - trying to take traces of chessboard appKartik K. Agaram2015-03-121-1/+6
|
* 709Kartik K. Agaram2015-02-071-2/+0
|
* 708Kartik K. Agaram2015-02-051-1/+1
|
* 690 - convention: '$' commands for debugging onlyKartik K. Agaram2015-02-011-20/+17
| | | | | | Swap printing generalized objects using arc's infrastructure to be the $-prefixed debug helper, while the erstwhile $print-key-to-host becomes the primitive print-character to host.
* 624 - no, that's all wrong, scratch 623Kartik K. Agaram2015-01-251-3/+3
|
* 623 - 'nochange' to guard against race conditionsKartik K. Agaram2015-01-251-3/+3
| | | | | | | | | I dunno, this may all be a wild goose chase. I haven't been disciplined in tagging in-out arguments in 'read-move' and its helpers. Maybe I should just drop those 'nochange' oargs in 'read' and 'write'. Maybe I should reserve output args only for return values that callers might actually care about, and use more conventional metadata like 'const' or 'unique' or 'inout' on other args.
* 620 - fix broken examples and tests againKartik K. Agaram2015-01-251-1/+1
| | | | | | | | | I just did this in 611; what's the point of all this if tests can't stay passing? I don't understand why buffered-stdin.mu needs to preempt itself. stdin and buffered-stdin somehow end up sharing a single circular buffer, that's probably causing a race condition.
* 619 - chessboard now working rightKartik K. Agaram2015-01-251-2/+18
| | | | | | 2 bugs found: a) Have to slurp the newlines. b) Have to clear the line-buffer at the start of each line.
* 618Kartik K. Agaram2015-01-251-0/+240
|
* 544 - text modes now called 'retro' & 'cursor'Kartik K. Agaram2015-01-121-93/+0
| | | | | | | | | | | | | Other options considered for 'retro': 'teletype': perhaps most accurate, but arcane 'chat': captures that you have to hit 'enter', but not the rendering 'wrap': captures the auto-wrap when printing text but not that you have to hit 'enter' when typing 'text': useful as a synonym of 'chat' while conveying more information in other meanings, but too generic, nobody will get it Why do the input and output options have to be entangled like this?
* 497 - strengthen the concept of 'space'Kartik K. Agaram2015-01-021-4/+4
| | | | | | | | | | | | | | | | | | | | 'default-scope' is now 'default-space' 'closure-generator' is now 'next-space-generator' The connection to high-level syntax for closures is now tenuous, so we'll call the 'outer scope' the 'next space'. So, let's try to create a few sentences with all these related ideas: Names map to addresses offset from a default-space when it's provided. Spaces can be strung together. The zeroth variable points to the next space, the one that is accessed when a variable has /space:1. To map a name to an address in the next space, you need to know what function generated that space. A corollary is that the space passed in to a function should always be generated by a single function. Spaces can be used to construct lexical scopes and objects.
* 496Kartik K. Agaram2015-01-021-0/+9
|
* 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).