| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Baremetal is now the default build target and therefore has its sources
at the top-level. Baremetal programs build using the phase-2 Mu toolchain
that requires a Linux kernel. This phase-2 codebase which used to be at
the top-level is now under the linux/ directory. Finally, the phase-2 toolchain,
while self-hosting, has a way to bootstrap from a C implementation, which
is now stored in linux/bootstrap. The bootstrap C implementation uses some
literate programming tools that are now in linux/bootstrap/tools.
So the whole thing has gotten inverted. Each directory should build one
artifact and include the main sources (along with standard library). Tools
used for building it are relegated to sub-directories, even though those
tools are often useful in their own right, and have had lots of interesting
programs written using them.
A couple of things have gotten dropped in this process:
- I had old ways to run on just a Linux kernel, or with a Soso kernel.
No more.
- I had some old tooling for running a single test at the cursor. I haven't
used that lately. Maybe I'll bring it back one day.
The reorg isn't done yet. Still to do:
- redo documentation everywhere. All the README files, all other markdown,
particularly vocabulary.md.
- clean up how-to-run comments at the start of programs everywhere
- rethink what to do with the html/ directory. Do we even want to keep
supporting it?
In spite of these shortcomings, all the scripts at the top-level, linux/
and linux/bootstrap are working. The names of the scripts also feel reasonable.
This is a good milestone to take stock at.
|
| |
|
|
| |
Give the bootstrap C++ program a less salient name.
|
| | |
|
| |
|
|
| |
Fix CI.
|
| | |
|
| |
|
|
| |
We've had this ability for Mu scenarios forever.
|
| |
|
|
| |
Also allow running a single test, to speed things up still further.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Just ran into first issue from using the portable /bin/sh rather than a
modern shell:
https://stackoverflow.com/questions/15744421/read-command-doesnt-wait-for-input
Turn on errexit everywhere.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Purge remaining `makefile`s, without breaking CI.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Reorganize build system to minimize duplication while handling 3
scenarios:
1. Locally running tests with `mu test`
2. Locally running tests until some layer with `build_and_test_until`
3. Running on Linux with `test_layers`
4. Running on Travis CI with multiple sharded calls to `test_layers`
One thing we drop at this point is support for OSX in test_layers. We
don't need it now that we have Travis CI working.
|
| |
|
|
|
| |
I'm already using grep and perl, bash is no worse, and it's *much* nicer
to work in than plain Bourne sh.
|
| |
|
|
|
|
| |
Since I switched to a Mac laptop (commit 2725) I've been lax in running
test_all_layers because I have to ssh into a server and whatnot. I
should just get CI setup somewhere..
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
I'm now running valgrind on my Linux server rather than my Mac laptop.
Little less convenient; let's see how it goes.
|
| | |
|
| |
|
|
|
|
|
| |
Make it easy to skip distracting valgrind errors when debugging more
obvious errors in early layers. Just throw a 'test' at the end of
build_and_test_until commands to not run valgrind (and make it a regular
test run).
|
| | |
|
| |
|
|
|
|
|
|
|
| |
No, 2001 is no good. Phony targets can't early-exit if everything's
built. New approach:
$ CFLAGS=-g make && ./mu test
etc.
|
| | |
|
| |
|
|
|
|
|
| |
Region to click on to edit is now reduced to just the menu bar for the
sandbox (excluding the 'x' for deleting the sandbox). The symmetry there
might be useful, but we'll see if the relative click area is
in line with how commonly the actions are performed.
|
| | |
|
| |
|
|
|
| |
Only core layers currently passing. Console apps are probably still
broken.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|