| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
I'm seeing *extremely* rare crashes due to some problem with negative
refcounts in the edit/ app. It's not using any concurrency at all, so
that's not the issue. Setting a tripwire to try and catch it. I'm going
to run:
mu --trace edit
..all the time for a while. And periodically restart when the trace
makes the program too sluggish to continue.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Fix CI. How does it work on my Mac without explicitly including errno?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- New plan
Primitives:
$open-file-for-reading
$open-file-for-writing
$read-from-file
$write-to-file
$close-file
The '$' prefix indicates that none of these are intended to be used
directly since they rely on type-system-busting numbers. Also that they
are just temporary hacks depending on primitives provided by the host
system. A putative 'Mu machine' would have very different primitives.
Testable interfaces:
- start-reading: starts a routine to read from a file and returns the
source where the contents will become available.
- start-writing: starts a routine to write to a file and returns the
sink where the contents can be provided.
Both operate on the real file-system if the first 'filesystem'
ingredient is 0.
Once you start them up you can read/write/close the channel as usual.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't know why this took so long to gel. I just needed to copy my
approach to screen management:
1. primitives layer (C++): simple, non-testable, non-safe operations.
2. wrappers layer (Mu): wrap operations with dependency-injected
versions that can take a fake file system.
3. scenario layer (C++): implement assume-filesystem that constructs a
fake file system.
4. scenario test layer (Mu): test out assume-filesystem in a test.
This commit implements step 1.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
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.
|