| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
| |
Systematize all the newlines while displaying test progress.
|
|
|
|
| |
Don't print the header for 'Mu tests' if there are no Mu tests to run.
|
| |
|
| |
|
| |
|
|
|
|
| |
Fix CI.
|
|
|
|
|
|
|
|
| |
The edit/ app without tracing turned on takes 22s to load up a
reasonably complex file and run 12 scenarios. Turn on tracing, and it
takes 68s. Turn on tracing just for app-level stashes, and it still
takes 40s. That's too much overhead, so let's keep it turned off by
default but give students an option to enable it at the commandline.
|
|
|
|
|
|
|
|
| |
The mu commandline now has four parts: options, commands (of which we
only have one so far: 'test'), files/directories and ingredients to pass
to 'main'. That cleans up the hacky ordering constraint we had earlier.
I've also cleaned up the usage message.
|
|
|
|
|
| |
Fix a bug with --test-only-app: the "App tests" header was only printing
after some app tests had run.
|
|
|
|
|
|
|
| |
This is part of efforts to allow students to transition gradually from
the sandbox to running programs directly on the commandline, writing
real scenarios, etc. Running on the commandline requires 'main', but
overriding 'main' would mess up edit/ which is itself a Mu program.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Have $print in console mode rotate through the screen rather than simply
block at the bottom.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Experimental: kinda support $print in console mode.
It's not perfect and probably will never be, because 'cout' buffers
differently from termbox primitives, which can cause console-aware
newlines to show up before other (console-oblivious) prints, like in
this example program:
def main [
open-console
$print [abc], 10/newline
$print [def], 10/newline
wait-for-some-interaction
close-console
]
And then there's the problem that there's no way for cout to update
Display_column. So mixing $print and print will be confusing.
Perhaps we should just not mess with Display_* variables inside $print?
But then we'll only ever be able to see a single line of $print at a
time.
|
| |
|
|
|
|
|
|
|
|
|
| |
Toss out Scenario_names. It's only checking if we load duplicate
scenarios, and we have independent checks for *running* duplicate
scenarios.
This has the salubrious effect of also allowing lessons to contain
regular text scenarios interspersed with their recipes.
|
|
|
|
| |
Thanks Ella Couch for running into this source of crashes.
|
|
|
|
|
|
|
|
| |
I'm going to focus on two projects for a while:
a) the testable interface for file system and network
b) a compiler translating some language to x86
b) might require first gaining some experience programming in Assembly.
|
| |
|
|
|
|
| |
Shouldn't break any existing programs using 'random'.
|
|
|
|
| |
Make 'stream' generic.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Fix a bug in phase ordering discovered while trying to stash cells in
the lambda compiler.
|
|
|
|
| |
Fix CI.
|
|
|
|
|
| |
Rewrite ingredients for 'trace' instructions just like 'stash'
instructions.
|
|
|
|
|
|
|
|
|
| |
Thanks Stephen Malina for helping run into this hole in support for
compound types.
When I created that assert (commit 2381, Nov 2015) I was thinking only
of type ingredients, and didn't realize that compound types could have
internal nodes with zero values.
|
|
|
|
|
| |
Manual tests for parse errors because scenarios can't handle assertion
failures yet.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Complicated logic to not run core tests. I only want to disable core
tests if:
a) I'm changing CFLAGS on the commandline (usually to disable
optimizations, causing tests to run slower in a debug cycle)
b) I'm not printing a help message (either with just 'mu' or
'mu --help')
c) I'm loading other files besides just the core.
Under these circumstances I only want to run tests in the files
explicitly loaded at the commandline.
This is all pretty hairy, in spite of my attempts to document it in
four different places. I might end up taking it all out the first time I
need to run core tests under all these conditions.
|
| |
|
|
|
|
| |
Parsing pairs of atoms.
|
| |
|
|
|
|
| |
Don't die if an instruction accidentally has too many products.
|
| |
|
|
|
|
|
| |
Reorganize parser to make room for parsing pairs. But first test for
pairs is still failing.
|