| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
One nice consequence of all my deduction of reply ingredients is that I
can insert the same fragment into recipes with different headers, and
everything works as long as reply instructions are implicitly deduced.
One thing I had to fix to make this work was to move reply-deduction out
of rewrite rules and turn it into a first-class transform, so that it
happens after tangling.
I'm glad to see the back of that hack inside <scroll-down>.
|
| |
|
|
|
|
|
| |
Still seeing repeated null refinements. Maybe my approach to fixing
those errors is fundamentally broken.
|
| |
|
|
|
|
|
| |
Not only can such recipes not have variants, their bodies too will be
oblivious to multiple variants or generics.
|
| |
|
| |
|
|
|
|
| |
It wasn't a phase-ordering issue after all..
|
|
|
|
|
|
| |
Now we try to be smarter about checking for presence in the Type array.
Still can't get generic duplex-list to work.
|
| |
|
|
|
|
|
|
|
|
|
| |
More flailing around trying to come up with the right phase ordering.
I've tried to narrow down each transform's constraints wrt transforms in
previous layers.
One issue that keeps biting me is the Type map containing empty records
because of stray [] operations. That's gotta be important.
|
| |
|
|
|
|
|
|
|
| |
A new externality is starting to make its presence felt.
Until I sort this out it's going to be hard to finish making duplex-list
generic.
|
| |
|
|
|
|
|
| |
I keep finding null property pointers and am fucking sick of wondering
if it's because of this horseshit.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
In the process we also convert types to sizes before we start running.
|
|
|
|
| |
Now it's not just tests that define recipe variants.
|
| |
|
| |
|
| |
|
|
|
|
| |
No test, but discovered when fixing list.mu.
|
| |
|
| |
|
|
|
|
| |
Clean up specialized recipes more thoroughly.
|
|
|
|
|
| |
Support for type ingredients anywhere.
I've been working on this since commit 2331.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Minor tweak: track all recipe variants.
|
| |
|
| |
|
| |
|
| |
|