| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This issue hasn't been noticed until now because I haven't been using variables
on the stack much.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's some worrisome memory corruption here between the call to max-stack-depth
and the callee picking up its args.
All this code is incredibly ugly as I start to wrestle with the challenges
of structured editors. I keep wanting to keep business logic separate from
rendering, but there are feedback loops from wanting to know where to render
the cursor. And I haven't even started trying to avoid full-screen renders
yet. That'll complect things even more. For now the data path for every
iteration of the render loop is:
process key
compute max depth needed (or any other global information needed for rendering)
render
|
| |
|
| |
|
|
|
|
|
|
|
| |
Simplify the app for now.
I'm not actually sure what sort of language I want to create here. So let's
not get ahead of ourselves inventing a whole new grid model and everything.
|
| |
|
|
|
|
| |
Extremely hacky initial stab at a 1-line editor.
|
|
|
|
| |
Fix CI since commit 6787.
|
|
|
|
|
|
|
| |
So far I've been assuming that read-key only works for ascii, and that
I'd need to get more sophisticated both for multi-byte utf-8 and multi-byte
terminal escape codes like arrow keys. Rather to my surprise, both work
fine. We just need to adjust the types to reflect this fact.
|
| |
|
|
|
|
| |
Roll back all buffering of Stdout.
|
|
|
|
| |
Yeah, this isn't working.
|
|
|
|
|
|
|
|
|
| |
tile is already visibly slow (49x212 screen) :/ So programmer needs more
control over performance.
But this may not be the right approach. That extra flush-stdout in tui.mu
suggests it's either going to be finicky, or we have to flush on every
attribute change. And going through a buffered-file may be slower. May.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
An extra test that should have been in commit 6781.
|
|
|
|
|
|
|
| |
Regression: segfault on `fn foo` without a block
I really need to turn the list of scenarios considered before populate-mu-function-header
into tests.
|
|
|
|
| |
This was surprisingly hard; bugs discovered all over the place.
|
| |
|
|
|
|
| |
Looks like Linux turns reads from stdout/stderr into stdin!
|
| |
|
|
|
|
| |
Print answers in decimal in apps/arith.mu
|
|
|
|
| |
This will take a while.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
In the process I had to go back and redo the `done-drawing?` logic everywhere.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Starting to gain confidence.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Fix a couple of subtle bugs.
- the VM was conditionally reading from the instruction stream, so that
other bugs got masked by decoding errors.
- push-n-bytes was clobbering eax.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|