| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Shorter branches above longer ones.
|
| |
|
|
| |
This is just the same as tests for a fake file-system.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This time we're opening real sockets so we might run into issues on
machines with firewalls. Macs for example flash up a dialog warning
people about a port being opened, though it shuts down immediately if
the test passes.
On the flip side, the test has greater verisimilitude. You don't really
need fakes except when you want to pin down the environment a test runs
in. The only way this test might be flaky is on a machine that has lots
of sockets open (so the random port opened by the test is in use for
something else). That and the firewall concern above. Hmm.
|
| |
|
|
| |
Its interface now mirrors that of 'read-event'.
|
| | |
|
| |
|
|
| |
Update syntax highlighting to not color numeric locations like literals.
|
| |
|
|
| |
Fix syntax highlighting for labels after commit 3552.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Cleaning up the console interfaces before we start changing the socket
interfaces to look like them. Reading from sockets need to be
non-blocking just like reading from the console.
|
| |
|
|
|
| |
Change the interface for reading a URL slightly so that we can directly
use the path in `assume-resources`.
|
| | |
|
| |
|
|
| |
Fix CI. Revert accidentally-added files.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
As long as Mu operates atop Unix, we need to make these assumptions.
Thanks Ella Couch for finding this loophole.
|
| |
|
|
|
|
|
| |
Tag all transforms as idempotent or not.
I'd fallen off this wagon.
I might even be getting it wrong. Something a type system should
automatically verify.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stop requiring jump instructions to explicitly provide a ':label' type
for jump targets.
This has been a source of repeated confusion for my students:
a) They'd add the ':label' to the label definition rather than the
jump target (label use)
b) They'd spend time thinking about whether the initial '+' prefix was
part of the label name.
In the process I cleaned up a couple of things:
- the space of names is more cleanly partitioned into labels and
non-labels (clarifying that '_' and '-' are non-label prefixes)
- you can't use label names as regular variables anymore
- you can infer the type of a label just from its name
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
More consistent definitions for jump targets and waypoints.
1. A label is a word starting with something other than a letter or
digit or '$'.
2. A waypoint is a label that starts with '<' and ends with '>'. It has
no restrictions. A recipe can define any number of waypoints, and
recipes can have duplicate waypoints.
3. The special labels '{' and '}' can also be duplicated any number of
times in a recipe. The only constraint on them is that they have to
balance in any recipe. Every '{' must be followed by a matching '}'.
4. All other labels are 'jump targets'. You can't have duplicate jump
targets in a recipe; that would make jumps ambiguous.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Type-check ingredients of 'start-running'
|
| | |
|
| | |
|
| |
|
|
|
| |
Keep color of control flow keywords from bleeding into that of function
headers.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Always check if next_word() returned an empty string (if it hit eof).
Thanks Rebecca Allard for running into a crash when a .mu file ends with
'{' (without a following newline).
Open question: how to express the constraint that next_word() should
always check if its result is empty? Can *any* type system do that?!
Even the usual constraint that we must use a result isn't iron-clad: you
could save the result in a variable but then ignore it. Unless you go to
Go's extraordinary lengths of considering any dead code an error.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Streamline the build process.
It's safest to always:
a) check if each output is `older_than` the inputs necessary to
construct it, and
b) update the output only if something changed.
However:
i) We don't yet have helpers to do b) in all situations, and
ii) combining a) and b) can cause `older_than` to spuriously report
files being updated.
So we'll always run exactly one of a) and b) and err on the side of
keeping the output reliable, at the risk of occasionally updating a file
unnecessarily and triggering unnecessary work downstream. Cross that
bridge when we run into it.
|
| |
|
|
| |
Don't update autogenerated *_list files unless necessary.
|
| |
|
|
| |
Coalesce all the management of number of failed scenarios.
|
| |
|
|
|
| |
Be consistent in checking for Scenario_testing_scenario when signalling
that a Mu scenario failed.
|
| |
|
|
| |
Coalesce some duplicate signalling that the current test failed.
|
| |
|
|
|
| |
Bugfix: refcounts were getting updated for the wrong ingredients in
'call' instructions.
|
| | |
|
| | |
|
| | |
|