| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've been saying for a while[1][2][3] that adding extra abstractions makes
things harder for newcomers, and adding new notations doubly so. And then
I notice this DSL in my own backyard. Makes me feel like a hypocrite.
[1] https://news.ycombinator.com/item?id=13565743#13570092
[2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning
[3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2
The implementation of the DSL was also highly hacky:
a) It was happening in the tangle/ tool, but was utterly unrelated to tangling
layers.
b) There were several persnickety constraints on the different kinds of
lines and the specific order they were expected in. I kept finding bugs
where the translator would silently do the wrong thing. Or the error messages
sucked, and readers may be stuck looking at the generated code to figure
out what happened. Fixing error messages would require a lot more code,
which is one of my arguments against DSLs in the first place: they may
be easy to implement, but they're hard to design to go with the grain of
the underlying platform. They require lots of iteration. Is that effort
worth prioritizing in this project?
On the other hand, the DSL did make at least some readers' life easier,
the ones who weren't immediately put off by having to learn a strange syntax.
There were fewer quotes to parse, fewer backslash escapes.
Anyway, since there are also people who dislike having to put up with strange
syntaxes, we'll call that consideration a wash and tear this DSL out.
---
This commit was sheer drudgery. Hopefully it won't need to be redone with
a new DSL because I grow sick of backslashes.
|
| | |
|
| |
|
|
| |
Another tweak for a light background.
|
| |
|
|
|
|
| |
Drop a wildcard in my edit shortcuts that's getting confused between apps/crenshaw2-1.subx
and apps/crenshaw2-1b.subx. We're pretty much always using the full filename
(excluding .subx extension) anyway.
|
| | |
|
| |
|
|
|
|
| |
Let's start highlighting all global variables in Red. Assembly programming
has a tendency to over-use them. They're a necessary evil, but we should
minimize the number of functions that access them.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
To search for instructions in .subx files, just run `:G 8b.*copy` inside
Vim without any quotes.
|
| | |
|
| | |
|
| |
|
|
| |
Get the 'edit' script working again with the 'EE' command in Vim.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
They uncovered one bug: in edit/003-shortcuts.mu
<scroll-down> was returning 0 for an address in one place where I
thought it was returning 0 for a boolean.
Now we've eliminated this bad interaction between tangling and punning
literals.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Be more disciplined about tagging 2 different concepts in the codebase:
a) Use the phrase "later layers" to highlight places where a layer
doesn't have the simplest possible self-contained implementation.
b) Use the word "hook" to point out functions that exist purely to
provide waypoints for extension by future layers.
Since both these only make sense in the pre-tangled representation of
the codebase, using '//:' and '#:' comments to get them stripped out of
tangled output.
(Though '#:' comments still make it to tangled output at the moment.
Let's see if we use it enough to be worth supporting. Scenarios are
pretty unreadable in tangled output anyway.)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
vim: Stop loading C++-specific syntax highlighting in non-C++ files.
I also figured out why the autocommand wasn't running on the first file:
my local setup for directory-specific vimrc files runs inside an
autocommand, and it runs autocommands recursively inside an autocommand,
and it runs only autocommands inside a 'LocalVimrc' autocommand group to
ensure infinite regress (autocommands running multiple times in
practice). And I'd forgotten this 'feature' of my vimrc setup by the
time I set this up for Mu.
|
| | |
|
| |
|
|
|
| |
Improvements to syntax highlighting, particularly for Mu code in C++
files.
|
| |
|
|
| |
We also do this in regular C++ now.
|
| | |
|
| |
|
|
| |
I've tried to update the Readme, but there are at least a couple of issues.
|
| | |
|
| | |
|
|
|
Don't prevent run-code from clobbering existing functions, but warn
because it makes traces easier to read if the different sections of a
test can be distinguished.
|