| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
First step to reducing typing burden. Next step: inferring types.
|
|
|
|
| |
Also standardized warnings.
|
|
|
|
|
|
|
|
|
| |
More verbose, but it saves trouble when debugging; there's never
something you thought should be traced but just never came out the other
end.
Also got rid of fatal errors entirely. Everything's a warning now, and
code after a warning isn't guaranteed to run.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Things I figured out:
- 'row' in render-screen doesn't perfectly track cursor-row in screen
- proximal cause was forgetting to add left:number to stop-printing
- trying to print to screen outside bounds was silently succeeding and
corrupting simulated memory
- if we silently ignore prints outside bounds things are fine
But why are prints outside screen bounds working? We should be accessing
screen data using 'index', and that's checking its bounds.
|
|
|
|
|
| |
Debugging simulated-screen support is taking too long, and I suddenly
have a few higher priorities.
|
|
|
|
| |
I'm writing to location 'screen' somehow that's not the raw location.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Still ugly as hell. Some tests failing, but they're most likely
wrong. We need to test cursor positioning at the level of the
environment and take it away from the responsibilities of individual
editors. Also bring back the line at the bottom of each editor.
The non-test run ('main' in edit.mu) is completely borked. Sluggish as
hell, and I can't seem to switch focus to the sandbox editor.
|
|
|
|
|
| |
Some reorg before we start plumbing 'reply' from 'run-interactive' to
return a string containing the results.
|
|
|
|
|
|
|
|
|
|
| |
We will need many other forms of isolation for these. For starters we're
going to have to replace most asserts with warnings that can be traced
so that the environment doesn't crash because of illegal code typed into
it.
New test is still failing. Just getting it to fail right was hard
enough.
|
| |
|
|
|
|
|
|
|
| |
It comes up pretty early in the codebase, but hopefully won't come up
in the mu level until we get to higher-order recipes. Potentially
intimidating name, but such prime real estate with no confusing
overloadings in other projects!
|
|
|