| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
For example:
x:number <- index y:address:array:number, 3
(forgetting to do a lookup)
Thanks Caleb Couch.
|
| |
|
|
| |
Should be a little bit more mnemonic.
|
| |
|
|
| |
First step to reducing typing burden. Next step: inferring types.
|
| | |
|
| | |
|
| |
|
|
| |
Also standardized warnings.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Eventually we might be able to get rid of die entirely.
This is just a preliminary stab at a random error. In the process I ran
into two issues that have impeded debugging before:
a) Naming conflicts within scenarios are a real no-no. I need to warn on
them, but the rules are getting complicated:
Always print warnings on redefine
But not in interactive mode
Or in scenarios checking warning behavior
Unless the scenario recipe itself is overridden
b) Now that we've added collect_layers and a long time can go between
traces, debugging is a minefield because trace lines don't print to
screen immediately after they're created. Need to do something about
that. Maybe explicitly trigger collection by tracing '\n' or something.
These are the next two items on my todo list.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Speeds up edit.mu tests by 10x, and shrinks memory usage by 100x.
We need a more efficient implementation of traces, but we can keep going
for now.
We didn't really need to reclaim memory just yet, after all. Mu is
pretty memory-efficient.
|
| |
|
|
| |
Finally, albeit too late for my demo.
|
| | |
|
| |
|
|
| |
All tests passing, but early layers are broken.
|
| |
|
|
|
| |
This is starting to look good! I need to add some tests for
render-string, but we'll see.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Some reorg before we start plumbing 'reply' from 'run-interactive' to
return a string containing the results.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Also added another failing test showing what behavior we want in the
programming environment. But there's no way to make use of querying
locations, since we're not planning any interaction with individual
sandboxes at the moment.
Instead of interacting with one sandbox at a time, which is the current
approach, we want to create dashboards out of multiple sandboxes at
once. Start with them non-interactive, that'll demonstrate 80% of the
new benefits. We'll add interactivity down the road.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
'run-interactive' now takes a string as input and returns a string as
output when it generates a result. As a result we also don't have to
worry about manual tests anymore, and it should now be reusable in
edit.mu.
|
| |
|
|
|
|
|
| |
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!
|
| |
|