| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you restore 2 sandboxes, the first render was setting
response-starting-row-on-screen on both, without ever rendering a
response. If the lower sandbox contained a print and rendered the screen
instead of the response, the original response-starting-row-on-screen
was never reset. If the process of running the sandboxes caused the
lower sandbox's title bar to move below the now-stale
response-starting-row-on-screen[1], editing the lower sandbox no longer
works.
[1] (Either because the upper sandbox prints to screen as well (causing
the first F4 to move the lower sandbox down by several lines), or
because a fresh sandbox is created with several lines before the first
F4 is hit.)
Current solution: never set response-starting-row-on-screen during
reload (or otherwise when there's no response).
This is hard to test right now because 'restore' is not a tested
interface, and I can't come up with another situation where the
response-starting-row-on-screen goes stale. So I'm now trying to keep
all changes to response-starting-row-on-screen close together. Another
idea is to add a check that the click row lies below the
response-starting row *and* above the start of the next sandbox. (But
what if there's no next sandbox?)
(This bug is really a regression, introduced last Sep in 2163.)
|
| |
|
|
|
| |
I spent the longest time trying to understand what bug 2268 fixed. But
it's being tested now.
|
| |
|
|
| |
Somehow this never transferred over from the Arc version until now.
|
| |
|
|
|
|
|
|
|
|
| |
When I first forked it from the edit/ app, I wasn't sure how to deal
with changing the recipe side when the only way the program accesses it
is with the untestable 'restore' hack. Now we introduce a little hook
into event-loop and pass in any updated recipe side directly.
In the process I've cleaned up several minor stylistic inconsistencies
between edit/ and sandbox/ apps.
|
| | |
|
| |
|
|
| |
See `cannot_write_tests_for`.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
It also seems useful that the number maps to the name of the file the
sandbox is saved in. However this mapping is currently a happy accident
and not actually tested.
I'm starting to switch gears and help make the editor useable with
many many sandboxes. This is just the first step of several.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the one major refinement on the C programming model I'm planning
to introduce in mu. Instead of Rust's menagerie of pointer types and
static checking, I want to introduce just one new type, and use it to
perform ref-counting at runtime.
So far all we're doing is updating new's interface. The actual
ref-counting implementation is next.
One implication: I might sometimes need duplicate implementations for a
recipe with allocated vs vanilla addresses of the same type. So far it
seems I can get away with just always passing in allocated addresses;
the situations when you want to pass an unallocated address to a recipe
should be few and far between.
|
| |
|
|
|
|
|
|
| |
Not entirely happy with this. Maybe we'll find a better name. But at
least it's an improvement.
One part I *am* happy with is renaming string-replace to replace,
string-append to append, etc. Overdue, now that we have static dispatch.
|
| | |
|
| | |
|
| |
|
|
|
| |
We still can't have decent tests in this variant.
Thanks Jack and Caleb Couch.
|
| |
|
|
| |
Now we can collect all traces, just modulating the depth.
|
| |
|
|
|
|
| |
With our new type checks it's no longer possible to expand traces
generated directly in the sandbox. So now there's yet another test that
we can't run in the sandbox/ app. Yet.
|
| | |
|
| | |
|
|
|
Thanks Jack and Caleb Couch for the idea.
|