| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
To find this I spent some time trying to diagnose when it happened but
there was no seeming pattern. I'd ended up with a small single-file .cc
and single-file .mu that reproduced one memory leak. Eventually I tried
deleting all type_tree and string_tree from it, and lo the leaks
vanished. I retried on all of edit (just loading), and the leaks
remained gone. At that point I switched tack and started looking at all
the core methods of these classes.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
But I realize that this won't actually streamline
replace_type_ingredients(), which needs that 'if (curr->left)
curr = curr->left' dance for an unrelated reason. So there's no
justification for entering into this big refactoring.
|
| | |
|
| | |
|
| |
|
|
| |
It's only for transient debugging.
|
| |
|
|
|
|
| |
to_string(): relatively stable fields only; for trace()
debug_string(): all fields; for debugging
inspect(): for a form that can be parsed back later
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Move code around to put all string-conversion functions in a single
section with a reasonable order, from recipe to instruction to reagent
to reagent members.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
I've been gradually Greenspunning reagents. Just go all the way.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We want to use the type 'recipe' for recipe *variables*, because it
seems nicer to say `recipe number -> number` rather than recipe-ordinal,
etc. To support this we'll allow recipe names to be mentioned without
any type.
This might make a couple of places in this commit more brittle. I'm
dropping error messages, causing them to not happen in some situations.
Maybe I should just bite the bullet and require an explicit
:recipe-literal. We'll see.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ok, now I'm a little happier about our type checking. Type checking lies
in three layers:
layer 21: checking types, usually at run-time in the VM or just before
layer 57: checking type names
layer 59: checking type names
It's taken me the process of writing this commit to convince myself that
all three layers check mappings for literal values in a consistent
manner. Layer 21 uses sizes, and layers 57/59 have whitelists, but
either way the goal is that number != character != boolean unless
mediated through a literal.
|
| |
|
|
|
| |
'append' also implicitly calls 'to-text' unless there's a better
variant.
|
| |
|
|
|
|
| |
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().
|
| |
|
|
|
| |
Starting to leave debug prints around once again, just in case one of
them is worth promoting to the trace..
|
| |
|
|
| |
Yet another bugfix as I trace through the last session with Caleb.
|
| |
|
|
|
|
|
|
|
| |
I was failing to specialize calls containing literals. And then I had to
deal with whether literals should map to numbers or characters. (Answer:
both.)
One of the issues that still remains: shape-shifting recipes can't be
called with literals for addresses, even if it's 0.
|
| |
|
|
| |
This time for the support for 'new' that was added in 2393.
|
| |
|
|
|
| |
One new issue: the traces for all tests are perturbed by the .mu files we
choose to load.
|
| | |
|
| | |
|
| |
|
|
|
| |
Fix that stray issue with a better phase ordering.
Another thing I'm not testing.
|
| |
|
|
|
|
|
|
|
|
|
| |
Still some spurious warnings.
This was an insane experience building out generics. Time to reflect.
Where did I go wrong? How did I end up writing no tests? Let's take some
time and go over the last 50 commits with a fine-tooth comb.
Generics seems to be the feature that has moved mu from a VM project to
a compiler project.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Got that idea to work with a special-case for 'new'. Requires parsing
new's first ingredient, performing the replacement, and then turning it
back into a string. I didn't want to replace NEW with ALLOCATE right
here, because then it messes with my invariant that transform should
never see a naked ALLOCATE.
Layer 11 still not working, but everything else is. Let's clean up
before we diagnose the new breakage.
|
| |
|
|
| |
Yup, type ingredients were taking size 1 by default.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
No, my idea was abortive. My new plan was to run no transforms for
generic recipes, and instead only run them on concrete specializations
as they're created.
The trouble with this approach is that new contains a type specification
in its ingredient which apparently needed to be transformed into an
allocate before specialization.
But no, how was that working? How was new computing size based on type
ingredients? It might have been wrong all along.
|
| |
|
|
| |
Starting to leave commented out prints again out of desperation.
|
| | |
|
| |
|
|
|
|
|
|
| |
New assertions still failing during tests.
This whole implementation of generic recipes is like an extended spike.
I don't have nearly enough tests. Ideally I'd have confidence in
generics once layer 59 passed its tests.
|
| |
|
|
|
|
|
| |
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.
|