about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 517Kartik K. Agaram2015-01-101-25/+19
| | | | Cleaner trace for 'convert-braces'.
* 516Kartik K. Agaram2015-01-101-20/+6
| | | | Cleanup trace a little.
* 515 - support time limits for threadsKartik K. Agaram2015-01-102-4/+164
| | | | | Disquieting that I can't make each of these five tests fail in isolation. We have to fix them all at once.
* 514Kartik K. Agaram2015-01-092-31/+35
|
* 513Kartik K. Agaram2015-01-091-2/+2
|
* 512 - update html renderingKartik K. Agaram2015-01-093-1361/+3096
|
* 511 - make 'sleep' clearerKartik K. Agaram2015-01-082-30/+32
|
* 510Kartik K. Agaram2015-01-081-2/+2
|
* 509Kartik K. Agaram2015-01-081-23/+23
|
* 508Kartik K. Agaram2015-01-071-1/+8
|
* 507 - time to focus on testing I/OKartik K. Agaram2015-01-061-0/+6
|
* 506 - continue 505Kartik K. Agaram2015-01-061-21/+27
| | | | Still no reason uncovered to avoid non-pointers.
* 505 - simplify tagged-valueKartik K. Agaram2015-01-053-42/+32
| | | | | | | I could swear there was an issue earlier where tagged-values had to contain pointers for some core function. But I can't find it anymore. Ok, assume we can store primitives in it and pointers only for aggregates (and-records and arrays).
* 504 - give up on graphics for nowKartik K. Agaram2015-01-052-325/+20
|
* 503 - start of a solution for drawing piecesKartik K. Agaram2015-01-053-28/+221
| | | | | | | | | | | Dog slow, though. Drawing the sprite for a single piece takes 12s or 30ms/pixel for 400 pixels. A third of that is the actual racket overhead of drawing pixel by pixel, which would in itself be too much. We need bitblts. (Black queen pixels derived from http://www.wpclipart.com/recreation/games/chess/chess_set_1, after scaling down to 40x40 and replacing external white pixels with transparent ones in Gimp.)
* 502 - start of a graphic chessboard appKartik K. Agaram2015-01-043-5/+153
| | | | Just prints an empty board so far.
* 501Kartik K. Agaram2015-01-021-1/+1
|
* 500Kartik K. Agaram2015-01-022-2/+2
|
* 499Kartik K. Agaram2015-01-021-1/+1
|
* 498 - how mu provides closuresKartik K. Agaram2015-01-022-27/+94
|
* 497 - strengthen the concept of 'space'Kartik K. Agaram2015-01-0211-136/+170
| | | | | | | | | | | | | | | | | | | | '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
|
* 495Kartik K. Agaram2015-01-022-1/+5
|
* 494 - yet another regressionKartik K. Agaram2015-01-021-1/+13
|
* 493Kartik K. Agaram2015-01-021-0/+2
|
* 492 - make chessboard more self-containedKartik K. Agaram2015-01-022-10/+16
|
* 491Kartik K. Agaram2015-01-021-0/+5
|
* 490Kartik K. Agaram2015-01-021-2/+2
|
* 489 - first regression in chessboardKartik K. Agaram2015-01-022-3/+4
| | | | Amazing how quickly we need tests or manual QA.
* 488Kartik K. Agaram2015-01-021-1/+7
|
* 487Kartik K. Agaram2015-01-021-1/+18
|
* 486Kartik K. Agaram2015-01-022-3/+3
|
* 485Kartik K. Agaram2015-01-021-29/+0
|
* 484Kartik K. Agaram2015-01-021-0/+2
|
* 482 - cleanupKartik K. Agaram2015-01-022-102/+101
| | | | | Now chessboard is faster than in my super-late-bound language (https://gist.github.com/akkartik/1291243). Reassuring.
* 481 - oh of course: 'int-canon.memory*'Kartik K. Agaram2015-01-022-106/+106
|
* 480 - trying to speed up chessboardKartik K. Agaram2015-01-023-37/+211
| | | | | | Computing length of a 32-long list takes 2x a 16-long list. But 64-long takes 3x 32-long. Why? No idea yet. No insights from counting calls.
* 479Kartik K. Agaram2015-01-023-172/+64
|
* 478 - snapshot while debugging chessboardKartik K. Agaram2015-01-013-64/+226
| | | | | | | | | | | | | | | | | | | | | | 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.
* 477 - reading moves in the chessboard appKartik K. Agaram2014-12-312-4/+108
|
* 476Kartik K. Agaram2014-12-311-2/+3
|
* 475 - support symbol literals, just as a convenienceKartik K. Agaram2014-12-312-1/+10
|
* 474Kartik K. Agaram2014-12-311-0/+88
|
* 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-302-10/+50
|
* 471 - experiment: chessboard appKartik K. Agaram2014-12-302-0/+65
| | | | | | 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).
* 470Kartik K. Agaram2014-12-301-1/+1
|
* 469 - warn on the bug of 464Kartik K. Agaram2014-12-301-0/+2
|
* 468 - slice test time by 65%Kartik K. Agaram2014-12-302-26/+27
| | | | | We achieve this by separating out the freezing of system software, which we needed to do anyway to address the duplication in 'init-fn'.
* 467 - 'convert-names' now supports space metadataKartik K. Agaram2014-12-302-19/+106
| | | | | | | | | To inform it about space metadata you have to tag environments with the function that generated them. Every function can only ever be called with environments generated by a single function. As an assembly-like language, mu requires closures to be called with an explicit environment, but it warns when the environment might not be what the function expects.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-17 23:24:51 +0000