Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | . | Kartik K. Agaram | 2021-08-08 | 3 | -5/+28 |
| | |||||
* | . | Kartik K. Agaram | 2021-08-07 | 1 | -0/+1 |
| | |||||
* | . | Kartik K. Agaram | 2021-08-07 | 4 | -10/+111 |
| | |||||
* | . | Kartik K. Agaram | 2021-08-06 | 1 | -3/+9 |
| | |||||
* | . | Kartik K. Agaram | 2021-08-06 | 1 | -8/+15 |
| | |||||
* | beginnings of a Slack archive reader | Kartik K. Agaram | 2021-08-06 | 2 | -0/+105 |
| | | | | | | | | I'm hackily depending on Python (3.something) to prototype the disk image creator. But no non-std libs. Once the disk image is created, I've validated that it can be loaded from disk without too much latency (assuming KVM). | ||||
* | . | Kartik K. Agaram | 2021-08-02 | 1 | -0/+4 |
| | |||||
* | better error handling on stray commas | Kartik K. Agaram | 2021-08-01 | 2 | -0/+47 |
| | |||||
* | . | Kartik K. Agaram | 2021-08-01 | 1 | -13/+16 |
| | |||||
* | . | Kartik K. Agaram | 2021-08-01 | 1 | -1/+3 |
| | |||||
* | support non-line-oriented processing in next-word | Kartik K. Agaram | 2021-07-29 | 16 | -36/+73 |
| | | | | Immediately this simplifies support for comments in image data. | ||||
* | maintain aspect ratio when rendering images | Kartik K. Agaram | 2021-07-29 | 3 | -8/+43 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-29 | 1 | -0/+2 |
| | |||||
* | downsampling photos makes the dithering seem worse | Kartik K. Agaram | 2021-07-29 | 1 | -2/+2 |
| | | | | We support 128px, so let's use the whole 128px. | ||||
* | . | Kartik K. Agaram | 2021-07-29 | 1 | -1/+1 |
| | |||||
* | shell: reliable image rendering | Kartik K. Agaram | 2021-07-29 | 1 | -0/+1 |
| | |||||
* | shell: rendering image definitions | Kartik K. Agaram | 2021-07-29 | 1 | -1/+68 |
| | | | | | | Not quite working yet. Only the very first rendering succeeds. After that any keypress triggers a second render which aborts. Image is getting corrupted in memory somehow. | ||||
* | shell: support loading 128x128px images | Kartik K. Agaram | 2021-07-28 | 6 | -10/+10 |
| | | | | | | I'm loading them in uncompressed ASCII format, and all streams and gap buffers all over the place need to get massively scaled up to 256KB capacity. But the tests don't yet run out of RAM, so I'll keep going. | ||||
* | shell: literal images | Kartik K. Agaram | 2021-07-28 | 6 | -8/+42 |
| | |||||
* | saving definitions containing string literals | Kartik K. Agaram | 2021-07-28 | 1 | -2/+0 |
| | | | | | | | This was the whole proximal goal in implementing balanced terminals. Printing these is still unreliable. It always surrounds in [], which may not work. | ||||
* | . | Kartik K. Agaram | 2021-07-28 | 2 | -22/+0 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-28 | 1 | -0/+142 |
| | |||||
* | shell: second notation for string literals | Kartik K. Agaram | 2021-07-28 | 1 | -5/+126 |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I've always been dissatisfied with the notion of escaping. It introduces a special-case meta-notation within the tokenizer, and the conventional approach leads to exponential "leaning toothpick syndrome" with each level of escaping. One potential "correct" solution is to keep string terminals parameterizable: [abc] => abc [=] => = [=[abc]=] => abc [=[a]bc]=] => a]bc [==[a]=]bc]==] => a]=]bc ..and so on. Basically the terminals grow linearly as the number of escapings grow. While this is workable, I'd like to wait until I actually need it, and then gauge whether the need is a sign of the stack growing too complex, with too many layers of notation/parsing. Mu's goal is just 3 notations, and it's going to require constant vigilance to keep that from growing. Therefore, for now, there are two notations for string literals, one symmetric and one balanced: "abc" => abc [abc] => abc The balancing notation permits nested brackets as long as they balance. [abc [def]] => abc [def] If you need unbalanced square brackets, use the symmetric terminals: "abc [def" => abc [def If you need double quotes inside strings, use the balanced notation: [abc "def] => abc "def If you need _both_ square brackets (whether balanced or unbalanced) and double quotes, you're currently shit outta luck. | ||||
* | shell: render image from pbm data stream | Kartik K. Agaram | 2021-07-27 | 5 | -5/+239 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-26 | 1 | -0/+74 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-26 | 1 | -0/+2 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-26 | 2 | -4/+16 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-26 | 1 | -1/+1 |
| | |||||
* | game of life in lisp | Kartik K. Agaram | 2021-07-26 | 3 | -47/+109 |
| | | | | | | | | Super slow; each frame is cleared as a sort of progress indicator while it computes the next frame. In the process I realize I need to adjust every single trace in the shell sources to be more fault-tolerant to a filled-up trace stream. | ||||
* | . | Kartik K. Agaram | 2021-07-26 | 3 | -10/+40 |
| | | | | | Smoked out some issues by rendering a single frame of Game of Life. Incredibly slow. | ||||
* | gracefully trace large multi-dimensional arrays | Kartik K. Agaram | 2021-07-26 | 1 | -4/+10 |
| | |||||
* | gracefully trace large arrays | Kartik K. Agaram | 2021-07-26 | 1 | -0/+8 |
| | |||||
* | palette operations now a bit faster | Kartik K. Agaram | 2021-07-26 | 1 | -7/+9 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-26 | 1 | -0/+6 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-26 | 1 | -3/+3 |
| | |||||
* | shell primitive: initialize array of some size | Kartik K. Agaram | 2021-07-26 | 1 | -0/+78 |
| | |||||
* | shell primitive: iset to mutate array at index | Kartik K. Agaram | 2021-07-25 | 1 | -1/+104 |
| | |||||
* | shell primitive: array index | Kartik K. Agaram | 2021-07-25 | 1 | -1/+82 |
| | |||||
* | shell: array type | Kartik K. Agaram | 2021-07-25 | 4 | -1/+161 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-25 | 1 | -9/+9 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-25 | 1 | -5/+5 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-25 | 1 | -4/+4 |
| | |||||
* | shell: starting to implement arrays | Kartik K. Agaram | 2021-07-25 | 2 | -5/+65 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-25 | 1 | -11/+10 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-24 | 1 | -0/+3 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-24 | 1 | -5/+4 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-22 | 2 | -31/+0 |
| | |||||
* | update memory map doc and anticipate a gotcha | Kartik K. Agaram | 2021-07-22 | 3 | -3/+15 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-20 | 3 | -46/+46 |
| | |||||
* | . | Kartik K. Agaram | 2021-07-20 | 39 | -531/+94 |
| |