| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we stash a value, mu does several levels of work for us:
a) First it inserts instructions above the stash to convert the value to
text using to-text-line.
b) to-text-line calls to-text. Both are shape-shifting, so multiple
levels of specialization happen.
To give a good error message, we track the 'stack' of current
specializations at the time of the error, and also check if the
offending instruction at the top-most level looks like it was inserted
while rewriting stash instructions.
Manual example (since booleans can't be stashed at the moment):
x:boolean <- copy 1/true
stash x
|
|
|
|
| |
Pretty hacky fix: we simply suppress static dispatch for main.
|
|
|
|
| |
Thanks Caleb Couch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- notes
bug in edit/ triggers in immutable but not master branch
bug triggered by changes to layer 059: we're finding an unspecialized call to 'length' in 'append_6'
hard to debug because trace isn't complete
just bring out the big hammer: use a new log file
length_2 from recipes.mu is not being deleted (bug #1)
so reload doesn't switch length to length_2 when variant_already_exists (bug #2)
so we end up saving in Recipe for a primitive ordinal
so no valid specialization is found for 'length' (bug #3)
why doesn't it trigger in a non-interactive scenario?
argh, wasn't checking for an empty line at end. ok, confidence restored.
|
| |
|
|
|
|
|
|
| |
We don't actually need skip_whitespace_AND_comments_BUT_NOT_newline
anywhere except next_word(). Perhaps what I should really do is split
the definition of next_word() into two variants..
|
|
|
|
|
|
| |
When skipping past some text (usually whitespace, but also commas and
comments) I need to always be aware of whether it's ok to switch to the
next line or not.
|
|
|
|
|
|
| |
Another gotcha uncovered in the process of sorting out the previous
commit: I keep using eof() but forgetting that there are two other
states an istream can get into. Just never use eof().
|
| |
|
| |
|
|
|
|
|
|
|
| |
Commands run:
$ sed -i 's/\([^. (]*\)\.find(\([^)]*\)) != [^.]*\.end()/contains_key(\1, \2)/g' 0[^0]*cc
$ sed -i 's/\([^. (]*\)\.find(\([^)]*\)) == [^.]*\.end()/!contains_key(\1, \2)/g' 0[^0]*cc
|
|
|
|
|
|
| |
Now we're starting to run up against the misbehavior introduced by
generics: Type tries to insert rows for type ingredients. That is a
no-no.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm still seeing all sorts of failures in turning on layer 11 of edit/,
so I'm backing away and nailing down every culprit I run into. First up:
stop accidentally inserting empty objects into maps during lookups.
Commands run:
$ sed -i 's/\(Recipe_ordinal\|Recipe\|Type_ordinal\|Type\|Memory\)\[\([^]]*\)\] = \(.*\);/put(\1, \2, \3);/' 0[1-9]*
$ vi 075scenario_console.cc # manually fix up Memory[Memory[CONSOLE]]
$ sed -i 's/\(Memory\)\[\([^]]*\)\]/get_or_insert(\1, \2)/' 0[1-9]*
$ sed -i 's/\(Recipe_ordinal\|Type_ordinal\)\[\([^]]*\)\]/get(\1, \2)/' 0[1-9]*
$ sed -i 's/\(Recipe\|Type\)\[\([^]]*\)\]/get(\1, \2)/' 0[1-9]*
Now mu dies pretty quickly because of all the places I try to lookup a
missing value.
|
| |
|
| |
|
|
|
|
|
| |
Deduce operation id from name during transform rather than load, so that
earlier transforms have a chance to modify the name.
|
| |
|
|
|
|
|
|
|
|
| |
I checked these commands:
$ mu x.mu
$ grep "===" .traces/interactive
$ grep "===\|---" .traces/interactive
|
|
|
|
|
|
|
|
|
|
|
| |
I've been growing lax on white-box testing when it's one of the three
big thrusts of this whole effort. Perhaps it was because I got too
obsessed with keeping traces stable and didn't notice that stable
doesn't mean "not changing". Or perhaps it's because I still don't have
a zoomable trace browser that can parse traces from disk. Or perhaps
$trace-browser is too clunky and discourages me from using it.
Regardless, I need to make the trace useable again before I work much
more on the next few rewriting transforms.
|
|
|
|
|
|
|
|
|
|
| |
Once a student has gotten used to recipes and ingredients using the
staged 'next-ingredient' approach there's no reason to avoid
conventional function headers. As an added bonus we can now:
a) check that all 'reply' instructions in a recipe are consistent
b) deduce what to reply without needing to say so everytime
c) start thinking about type parameters for recipes (generic functions!)
|
| |
|
|
|
|
|
| |
Now we always consider words to be terminated at () and {}.
We also always skip commas.
|
| |
|
|
|
|
| |
Still trying to come up with clean lexing rules.
|
| |
|
|
|
|
|
| |
Switch format for tracing reagents in preparation for trees rather than
arrays of properties.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current plan:
parsing {x: foo, y: bar} syntax for reagents
parsing s-expr syntax for properties
supporting reverse instructions (<-)
parsing s-expr syntax for recipe headers (recipe number number -> number)
static dispatch
generic functions
type-checking higher-order functions
type of delimited continuations? need more type information
First step is done, and the second partially so.
|
|
|
|
|
|
|
| |
At the lowest level I'm reluctantly starting to see the need for errors
that stop the program in its tracks. Only way to avoid memory corruption
and security issues. But beyond that core I still want to be as lenient
as possible at higher levels of abstraction.
|
| |
|
|
|
|
|
| |
Follow-up to 2147, which switched transform_all to only run once, after
loading all layers.
|
|
|
|
|
| |
This will let me create separate 'main' recipes at each layer so people
can interact with less featureful versions.
|
| |
|
|
|
|
|
| |
I ran into this inside 'reload' when I left a trailing comment at the
end of the editor.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Finally terminate the experiment of keeping debug prints around. I'm
also going to give up on maintaining counts.
What we really need is two kinds of tracing:
a) For tests, just the domain-specific facts, organized by labels.
b) For debugging, just transient dumps to stdout.
b) only works if stdout is clean by default.
Hmm, I think this means 'stash' should be the transient kind of trace.
|
| |
|
| |
|
| |
|
|
|
|
| |
Standardize test names.
|
|
|
|
| |
Should be a little bit more mnemonic.
|
|
|
|
| |
First step to reducing typing burden. Next step: inferring types.
|
| |
|
|
|
|
|
|
| |
A couple of times now I've accidentally named a scenario the same thing
as a recipe inside it that I define using 'run' or something. The
resulting infinite loop is invariably non-trivial to debug.
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
All tests passing, but early layers are broken.
|
|
|
|
|
|
|
| |
It comes up pretty early in the codebase, but hopefully won't come up
in the mu level until we get to higher-order recipes. Potentially
intimidating name, but such prime real estate with no confusing
overloadings in other projects!
|