about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 7158Kartik Agaram2020-11-024-372/+310
|
* 7157Kartik Agaram2020-11-016-101/+96
|
* 7156Kartik Agaram2020-11-012-3/+6
|
* 7155Kartik Agaram2020-11-011-12/+12
| | | | apps/arith.mu compiling again.
* 7154Kartik Agaram2020-11-0112-369/+141
|
* 7153Kartik Agaram2020-11-012-3/+7
| | | | Bugfix in computing the label a return should jump to.
* 7152 - 'return' instructionKartik Agaram2020-11-014-1/+644
| | | | | | https://github.com/akkartik/mu/issues/45#issuecomment-719990879, task 1. We don't have checking for it yet. Soon.
* 7151Kartik Agaram2020-11-012-97/+46
| | | | Drop pending tests for the old plan of liveness analysis.
* 7150Kartik Agaram2020-10-311-0/+16
|
* 7149Kartik Agaram2020-10-311-1/+1
|
* 7148Kartik Agaram2020-10-312-5/+2
|
* 7147Kartik Agaram2020-10-312-8/+14
|
* 7146Kartik Agaram2020-10-312-173/+173
|
* 7145 - roll back to 7143Kartik Agaram2020-10-301-89/+174
|
* 7144 - tmp: redo checks for function outputsKartik Agaram2020-10-301-174/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | This isn't done, but an intermediate snapshot seems worth capturing. Back in March (commit 6082), I made a plan to check writes to function outputs using liveness analysis. I've been shying away from actually acting on this plan ever since. In recent weeks I've had this gap bite me three times. Returning to the problem now, I think I don't actually need to compute variable liveness. The compiler can, I think, do the same thing for output registers whether their variables are alive or dead. The new rule is this: Once a register gets a function output written to it, no local is popped into it. Instead of popping outer locals to the register, we simply increment the stack and keep going. Since the function output will continue to live on the vars stack past this point (see clean-up-block), any attempts to read shadowed variables will throw an error as usual. This rule is also now easy to explain to people, I think. "You wrote the function output. Now the register can't be used for anything else." It's really cool that this works (if it does). Another fruit from "Mu's lovely property."
* 7143Kartik Agaram2020-10-292-1/+1
| | | | Am I starting to have too much code duplication?
* 7142Kartik Agaram2020-10-292-0/+4
|
* 7141Kartik Agaram2020-10-292-4/+1
|
* 7140Kartik Agaram2020-10-291-0/+11
|
* 7139 - type-check compute-offsetKartik Agaram2020-10-292-13/+908
|
* 7138 - type-check array 'length' instructionKartik Agaram2020-10-2916-6/+838
|
* 7137Kartik Agaram2020-10-282-2/+2
|
* 7136Kartik Agaram2020-10-282-10/+10
|
* 7135 - type-check write-to-streamKartik Agaram2020-10-282-0/+668
| | | | Lots of copy-pasta.
* 7134 - type-check read-from-streamKartik Agaram2020-10-282-0/+562
|
* 7133Kartik Agaram2020-10-281-2/+2
|
* 7132Kartik Agaram2020-10-281-0/+0
|
* 7131Kartik Agaram2020-10-281-1/+1
|
* 7130 - back to the Mu compiler for a spellKartik Agaram2020-10-272-0/+106
| | | | | Hacking on apps has created some urgency now for several additional safety checks.
* 7129 - tile: allow bindings anywhereKartik Agaram2020-10-271-7/+7
| | | | | | | | | | Amazing how easy this was. And it does feel more intuitive. If I decide at some point that I want to bind something to a name I don't usually want to lose the entire line after that point. It also sidesteps for now the thorny question of whether to permit organically switching to a new line (rather than using the 'name value' hotkey), and how that should work.
* 7128Kartik Agaram2020-10-271-5/+11
| | | | More consistent spacing in sandbox render.
* 7127Kartik Agaram2020-10-273-1/+209
|
* 7126Kartik Agaram2020-10-271-5/+5
|
* 7125 - tile: fade out values on the stackKartik Agaram2020-10-271-4/+1
|
* 7124 - tiles: better 'lines' primitiveKartik Agaram2020-10-273-14/+58
|
* 7123 - tile: truncate string if necessaryKartik Agaram2020-10-265-3/+124
|
* 7122 - tile: styling for stringsKartik Agaram2020-10-261-1/+6
|
* 7121Kartik Agaram2020-10-261-5/+11
| | | | | | | Starting to polish 'line-count' demo: filename line-count = filename open lines len
* 7120 - tile: array of lines from fileKartik Agaram2020-10-266-2/+106
| | | | Requires a quick hacky change to Mu compiler.
* 7119 - tile: new primitive to slurp file contentsKartik Agaram2020-10-262-1/+41
| | | | | Stack display is messed up when file contents contain newlines. Ignoring that for now.
* 7118Kartik Agaram2020-10-261-3/+5
|
* 7117Kartik Agaram2020-10-261-2/+4
|
* 7116 - tile: regression in typing in stringsKartik Agaram2020-10-262-55/+46
| | | | We really need to clean up the Mu compiler's logic around function outputs.
* 7115Kartik Agaram2020-10-264-16/+16
|
* 7114Kartik Agaram2020-10-261-0/+3
|
* 7113Kartik Agaram2020-10-261-2/+12
|
* 7112 - tile: arrays of non-integersKartik Agaram2020-10-264-73/+125
|
* 7111Kartik Agaram2020-10-261-36/+41
|
* 7110Kartik Agaram2020-10-261-0/+54
| | | | | | | | | | Some more helpers that I want to avoid using, but they help me gain confidence in the current implementation of file handles. Manual test: "x" open dup read swap read Assumes there's a file called `x` in the current directory that contains at least two (short!) lines.
* 7109Kartik Agaram2020-10-254-5/+4
| | | | | | | | | | | | | | | | | | | Turns out I've been including some unnecessary files when building apps/mu! Treeshaken stats before: LoC 26258 => 9717 LoC including common libraries: 29736 => 12719 binary size: 406K => 79K After: LoC 26258 => 9717 LoC including common libraries: 28322 => 12370 binary size: 406K => 77K So our treeshaking isn't perfect. No surprise there.. The treeshaken build also starts to fail without the one-liner change to mu.subx, which looks like a bug in the treeshaker.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-06-23 20:15:51 +0000