| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Still very incomplete:
a) we perform the check at runtime
b) tests for edit and sandbox apps no longer work; we can't fix them
until we get type parameters in both containers and recipes (because
list and list operations need to become generic).
|
| |
|
|
|
|
|
|
| |
We still can't check ingredient types, and even this is still a run-time
check. We'll need to start tracking recipe signatures at some point.
I've had to introduce a hack called /skiptypecheck. Time to get generics
working.
|
| |
|
|
|
|
|
|
|
| |
Front-loads it a bit more than I'd like, but the payoff is that other
recipes will now be able to describe the type checks right next to their
operation.
I'm also introducing a new use of /raw with literals to indicate unsafe
typecasts.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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..
|
| | |
|
| |
|
|
| |
Now we can make use of all the depths from 1 to 99.
|
| |
|
|
|
|
|
|
|
|
| |
Also ensure we don't render unnecessarily.
This is really where I want a formal type-like system to help me.
All functions have paired calls to hide-screen and show-screen, except
for the one in main.
Only functions at the 'topmost' level are expected to hide/show.
|
| |
|
|
|
|
|
| |
http://250bpm.com/blog:57
Funnily, the new idea I finally came up with in 'read' was already
mirrored above in recipe 'write'.
|
| | |
|
| | |
|
| |
|
|
| |
Should be a little bit more mnemonic.
|
| |
|
|
| |
First step to reducing typing burden. Next step: inferring types.
|
| |
|
|
|
|
|
| |
The recent session makes me weary of deleting comment counts from inside
strings, and the newlines everywhere take up vertical space. Considered
println like pascal/ruby, but I'd like something I can add/remove at the
end of existing prints. So this hack for $print.
|
| |
|
|
|
| |
Bring back my optimizations for avoiding unnecessary work. But they
shouldn't be needed for correctness, and they aren't.
|
| | |
|
| |
|
|
| |
I was counting locations when I should have been counting elements.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
But still no difference in either memory footprint or in running time.
This will teach me -- for the umpteenth time -- to optimize before
measuring.
|
| |
|
|
|
| |
Turns out to not affect memory utilization or run-time. At all.
But still looks nicer and requires less fudging on our part.
|
| |
|
|
|
| |
No, that's a false alarm. There's just a larger screen to manipulate.
But the size of the screen doesn't change in interactive mode.
|
| |
|
|
|
|
| |
Simpler gradient computation.
But in the end it looks better when the gradient is so subtle as to be
irrelevant. Might as well eliminate the gradient altogether.
|
| | |
|
| |
|
|
|
| |
Requires better support for special variable names in scenarios like
'screen' and 'console'.
|
| |
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While pushing out color support in fake screens I realized I've been
complecting the special-case of a special-case to transform
literal-string arguments for 'new'. As a result I hadn't been catching
bad habits like giving its arg the wrong type. Now we have cleaner
separation of the two variants of 'new', a few more checks, and better
error messages when we mis-call it.
Aside: I've added a third goto target. Sliding into spaghetti? Keep an
eye on it.
This goto might become a common pattern: a layer hooking into a previous
one to prevent it from happening. In this case new on literal-strings
prevents the transform for new from triggering.
|
| |
|
|
|
|
|
|
|
|
| |
After like 40 seconds (because of the 120-column screen), but whatever.
The final bug was that clear-screen wasn't actually working right for
fake screens.
(The trace is too large for github, so I'm going to leave it out for
now.)
|
| |
|
|
|
| |
Delete comment-out marker from inside mu strings. Have to do this
manually 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.
|
| |
|
|
| |
..now that we support non-integers.
|
| |
|
|
|
|
|
|
| |
Mu allows us to use multiple ingredients/products without commas, but
make sure we don't.
$ grep "<- [^ ]\+ [^#\[,]* [^#\[,]*$" *
$ grep "^[ ]*[^ #,][^#,]* [^#,]* <- " *
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
Just to put all our new test primitives through their paces, and iron
out any kinks.
Just the one chessboard scenario is taking 1.5-2.5x all the tests we've
written so far. But we're starting from a faster baseline, that was the
point of the C++ port. I also have -O3 optimizations in my back-pocket.
|