| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
Always show recipe name where error occurred. But don't show internal
'interactive' name for sandboxes, that's just confusing.
What started out as warnings are now ossifying into errors that halt all
execution. Is this how things went with C and Unix as well?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mu still isn't so optimized that I can be profligate with spare cycles.
Instead we'll follow termbox-go's example and create a new API routine
called tb_sync() (after discussion with termbox's author). Now we only
need use tb_sync() on ctrl-l. For everything else use the optimized
render.
Now I think I've eradicated all signs of "cursor thrashing" during
refresh, in spite of how slow mu is as an interpreted language. We only
render the whole screen in some situations, and only if there's no more
input, and even then we only refresh the parts of the screen that
changed.
Thanks Jack and Caleb Couch for providing the impetus behind commits
2109-2113.
I've been lazy about writing tests for all this, but it's still good to
know I could, if I wanted to.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Finally terminate the experiment of keeping debug prints around. I'm
also going to give up on maintaining counts.
What we really need is two kinds of tracing:
a) For tests, just the domain-specific facts, organized by labels.
b) For debugging, just transient dumps to stdout.
b) only works if stdout is clean by default.
Hmm, I think this means 'stash' should be the transient kind of trace.
|
|
|
|
| |
Cleanup 2078.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Termbox had been taking shortcuts when it thinks the screen hasn't
changed, which doesn't work if some other process messes up the screen.
The Go version has a Sync method in addition to Flush/tb_present for
precisely this eventuality. But it feels like an unnecessary
optimization given C's general speed. Just drop it altogether.
---
This took me a long time to track down, and interestingly I found myself
writing a new tracing primitive before I remembered how to selectively
trace just certain layers during manual tests. I'm scared of generating
traces not because of performance but because of the visual noise. Be
aware of this. I'm going to clean up $log now.
Maybe I should also stop using $print..
|
|
|
|
|
|
| |
Mouse clicks towards the right of very wide windows weren't working.
Turns out to be a limitation of the X10 protocol:
https://github.com/nsf/termbox-go/issues/32
|
|
|
|
|
| |
Environment much more responsive now. And it doesn't slow down as much
just because I'm on a larger screen.
|
|
|
|
|
| |
This was important because somebody connecting on tmux would mess up the
environment.
|
|
|
|
| |
Also standardized warnings.
|
|
|
|
| |
The trick is to check for more events and not bother rendering if so.
|
| |
|
|
|
|
|
|
|
| |
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!
|
|
|
|
| |
Had to take control of tb_present() after all. Termbox was wise.
|
|
|
|
|
| |
But it doesn't work, because moving the cursor inside 'render' also
starts displaying it again.
|
|
|
|
|
|
| |
Snapshot in switching editor-data.cursor to editor-data.before-cursor.
But I have trouble coercing events to touch events, even though using
the integer tag 2 for the conversion works.
|
|
|
|
|
|
|
|
| |
Another bug in manually running the editor. At least show the error
message when you raise warnings in console mode.
Later we'll want to create a separate side channel and transparently
plumb warnings to the 'menu bar' of the editor..
|
| |
|
|
|
|
|
| |
Only core layers currently passing. Console apps are probably still
broken.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Just figured out why a first keystroke of backspace was sending me out
for a spin: run_interactive needs all early exits that don't actually
run anything to increment the current_step_index(). FML, this is lousy..
|
| |
|
| |
|
|
|
|
| |
Just foreground color for now.
|
| |
|
|
|
|
|
|
|
| |
CRLF still shows as two newlines, though. Cross that bridge when we get
to it.
The new chessboard test is still hanging, though.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I added one test to check that divide can return a float, then hacked at
the rippling failures across the entire entire codebase until all tests
pass. Now I need to look at the changes I made and see if there's a
system to them, identify other places that I missed, and figure out the
best way to cover all cases. I also need to show real rather than
encoded values in the traces, but I can't use value() inside reagent
methods because of the name clash with the member variable. So let's
take a snapshot before we attempt any refactoring. This was non-trivial
to get right.
Even if I convince myself that I've gotten it right, I might back this
all out if I can't easily *persuade others* that I've gotten it right.
|
| |
|
|
|
|
|
|
| |
Lots mixed into this commit:
some off-by-one errors in display.cc
a new transform to translate jump labels that I'd somehow never gotten around to supporting
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I tried to bring too much into this commit, and paid the price with some
debugging effort. Still havent't tried to enable line buffering, but
I'll take a snapshot.
Some tests are failing because of the huge hack in the scheduler.
For a while I thought there was a bug in termbox because I kept seeing
segfaults and valgrind complained about out-of-bounds access. But that
was just subsidiary threads trying to print to the screen after I'd
returned to console mode.
Maybe I should add a test for send-keys-to-channel. Or just use a fake
keyboard rather than a channel.
And *then* there's the fact that the interaction is molasses slow.
Slower than the arc version even though the tests run so much faster.
And what's with the long pauses in printing strings to screen?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All primitives now always write to all their products. If a product is
not used that's fine, but if an instruction seems to expect too many
products mu will complain.
In the process, many primitives can operate on more than two ingredients
where it seems intuitive. You can add or divide more than two numbers
together, copy or negate multiple corresponding locations, etc.
There's one remaining bit of ugliness. Some instructions like
get/get-address, index/index-address, wait-for-location, these can
unnecessarily load values from memory when they don't need to.
Useful vim commands:
%s/ingredients\[\([^\]]*\)\]/ingredients.at(\1)/gc
%s/products\[\([^\]]*\)\]/products.at(\1)/gc
.,$s/\[\(.\)]/.at(\1)/gc
|
|
I've tried to update the Readme, but there are at least a couple of issues.
|