| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Drop a few debug prints. Hopefully now we need never duplicate trace
statements and can instead just dump them to screen.
I'll soon need the ability to selectively dump traces for a specific
label.
|
| |
|
|
|
|
| |
In the process I've also altered the API of $read-from-socket to return
a boolean (eof?) rather than the number of bytes read (which is implicit
in the length of the returned array).
|
| |
|
|
| |
The bugfix of commit 3517 allows us to drop this redundant condition.
|
| |
|
|
|
| |
The notion of blocking is just to enable certain kinds of tests. We
should never be using it in production code.
|
| |
|
|
|
|
| |
I had this early on. Why did I delete it? Was it because I was only
flushing the current trace when I started on the next one? We don't have
that problem anymore..
|
| |
|
|
| |
Bugfix: allow 'new' to be passed in type abbreviations.
|
| |
|
|
|
|
|
|
| |
Let's constrain 'push' on lists to always modify its ingredient.
That makes some possibilities more verbose, such as lists that share a
common tail. But may be worthwhile to get better errors in the common
use-case.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Undo commit 3500; turns out we need the duplicate scenario names for
good test failure messages.
|
| |
|
|
|
|
|
|
| |
Better implementation of commit 3445: not requiring types for special
variables in scenarios. It turned out that it wasn't working anytime we
needed to call 'get' on a special variable inside a scenario. After
moving that work to an earlier transform we can now use 'filesystem'
without a type inside scenarios.
|
| | |
|
| | |
|
| | |
|