| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Still iterating on the right way to handle incorrect number of
ingredients. My first idea of creating null results doesn't really work
once they're used in later instructions. Just add a warning at one place
in the run loop, but otherwise only add products when there's something
to save in them.
Undoes some work around commit 1886.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
For example:
x:number <- index y:address:array:number, 3
(forgetting to do a lookup)
Thanks Caleb Couch.
|
| | |
|
| | |
|
| |
|
|
| |
Also standardized warnings.
|
| |
|
|
|
|
|
|
|
| |
More verbose, but it saves trouble when debugging; there's never
something you thought should be traced but just never came out the other
end.
Also got rid of fatal errors entirely. Everything's a warning now, and
code after a warning isn't guaranteed to run.
|
| |
|
|
|
|
| |
Starting to feel some need to test this persistence support. Next time
I'll create a fake storage handle and support for 'assume-storage
filename'.
|
| | |
|
| |
|
|
|
|
|
| |
No restore. We'll have to do that manually for the first lesson.
The version control is also super ugly; every save creates a new commit.
But that's ok; version control is just the backup of last resort.
|
| | |
|
| |
|
|
|
| |
We want to avoid accidentally mixing lessons into ourselves. Require
users to git-enable it first.
|
|
|
Very rudimentary ability to read/write from file+version control. No
control over name.
Recipes now saved. But what to do about sandboxes?
|