| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
| |
Be more consistent that 'return' is the name of the instruction, and
'reply' just a synonym. Maybe I should take it out. It wouldn't affect
the recipe/ingredient terminology while I teach..
|
| |
|
|
|
| |
Finally after much massaging, the 'address' and 'new' layers are
adjacent.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Show more thorough information about instructions in the trace, but keep
the original form in error messages.
|
| |
|
|
|
|
|
|
| |
As outlined at the end of 2797. This worked out surprisingly well. Now
the snapshotting code touches fewer layers, and it's much better
behaved, with less need for special-case logic, particularly inside
run_interactive(). 30% slower, but should hopefully not cause any more
bugs.
|
| |
|
|
|
|
|
| |
Simplify 2790 by simply not computing any type->value inside
parse_type_tree. It now only generates names, and it turns out the
consumers handle the absence of values anyway. Now parse_type_tree no
longer pollutes the Type_ordinal table with type ingredients.
|
| |
|
|
|
|
|
|
| |
The issue alluded to in the previous 2789 is now fixed. I'm not happy
with my solution, though. I pollute Type_ordinal with type ingredients
in parse_type_tree and simply ignore such entries later on. I'd much
rather avoid the pollution in the first place, but I'm not sure how to
do that..
|
| |
|
|
| |
This should eradicate the issue of 2771.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I'm dropping all mention of 'recipe' terminology from the Readme. That
way I hope to avoid further bike-shedding discussions while I very
slowly decide on the right terminology with my students.
I could be smarter in my error messages and use 'recipe' when code uses
it and 'function' otherwise. But what about other words like ingredient?
It would all add complexity that I'm not yet sure is worthwhile. But I
do want separate experiences for veteran programmers reading about Mu on
github and for people learning programming using Mu.
|
| | |
|
| |
|
|
|
| |
Only Hide_errors when strictly necessary. In other places let test
failures directly show the unexpected error.
|
| |
|
|
|
|
| |
Ok, we don't need that check after all, because the
type_ingredient_names.empty() check earlier in the layer prevents it
from ever triggering.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All my attempts at staging this change failed with this humongous commit
that took all day and involved debugging three monstrous bugs. Two of
the bugs had to do with forgetting to check the type name in the
implementation of shape-shifting recipes. Bug #2 in particular would
cause core tests in layer 59 to fail -- only when I loaded up edit/! It
got me to just hack directly on mu.cc until I figured out the cause
(snapshot saved in mu.cc.modified). The problem turned out to be that I
accidentally saved a type ingredient in the Type table during
specialization. Now I know that that can be very bad.
I've checked the traces for any stray type numbers (rather than names).
I also found what might be a bug from last November (labeled TODO), but
we'll verify after this commit.
|
| |
|
|
|
|
|
| |
Start using type names from the type tree rather than the property tree
in most places. Hopefully the only occurrences of
'properties.at(0).second' left are ones where we're managing it. Next we
can stop writing to it.
|
| |
|
|
| |
Include type names in the type tree. Though we aren't using them yet.
|
| |
|
|
| |
It's only for transient debugging.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stack of plans for cleaning up replace_type_ingredients() and a couple
of other things, from main problem to subproblems:
include type names in the type_tree rather than in the separate properties vector
make type_tree and string_tree real cons cells, with separate leaf nodes
redo the vocabulary for dumping various objects:
do we really need to_string and debug_string?
can we have a version with *all* information?
can we have to_string not call debug_string?
This commit nibbles at the edges of the final task, switching from
member method syntax to global function like almost everything else. I'm
mostly using methods just for STL in this project.
|
| |
|
|
|
|
|
|
|
|
| |
Still not done, though:
a) There's a few memory leaks to track down, including one in hash from
2668.
b) replace_type_ingredients has gotten *even* uglier. I need to rethink
it.
|
| |
|
|
|
|
|
|
|
|
|
| |
Eliminated a few holes, gained more clarity on the shape of others.
Maybe I was sleep-deprived, but this was really hard until I wrote a few
unit tests directly on replace_type_ingredient.
Still one flaw remaining: the type-checker isn't smart enough to handle
'merge' for all the new cases. Tests pass since we don't use those
features outside C++ tests yet.
|
| | |
|
| |
|
|
| |
I've been gradually Greenspunning reagents. Just go all the way.
|
| | |
|
| |
|
|
|
|
|
| |
The rule is: a container type's size must be fixed. Arrays can violate
this rule if the array length isn't included in the type. But we haven't
been warning about this, and 'new' has been silently turning array
elements to be empty.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
Some more structure to transforms, and flattening of dependencies
between them.
|
| |
|
|
| |
It's just the other direction we want to avoid.
|
| |
|
|
|
| |
/raw is to express absolute addresses
/unsafe is to sidestep type-checking in test setup
|
| |
|
|
| |
Thanks Caleb Couch.
|
| | |
|
| |
|
|
|
|
| |
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().
|
| | |
|
| |
|
|
|
| |
One new issue: the traces for all tests are perturbed by the .mu files we
choose to load.
|
| |
|
|
|
|
|
| |
Is that like a Maybe type in a type system? No it's more, it captures
the wistful longing of several hours spent trying to make an assertion
true. Not even by moving my phases relating to the types around could I
make this assertion true.
|
| | |
|