| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
I'd not paid any attention to it so far, but I need to do so from now
on.
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
In the process we also convert types to sizes before we start running.
|
|
|
|
|
| |
Deduce operation id from name during transform rather than load, so that
earlier transforms have a chance to modify the name.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
Always show recipe name where error occurred. But don't show internal
'interactive' name for sandboxes, that's just confusing.
What started out as warnings are now ossifying into errors that halt all
execution. Is this how things went with C and Unix as well?
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Adjust spaces in 'stash'.
|
| |
|
|
|
|
|
|
| |
This can happen if 'canonize' fails. Make sure it doesn't kill mu.
Thanks Caleb Couch.
|
|
|
|
|
| |
More friendly way to 'stash' stuff in the trace so that you can toggle
lines of code to see their stashed traces.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Should be a little bit more mnemonic.
|
|
|
|
| |
First step to reducing typing burden. Next step: inferring types.
|
| |
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Things I figured out:
- 'row' in render-screen doesn't perfectly track cursor-row in screen
- proximal cause was forgetting to add left:number to stop-printing
- trying to print to screen outside bounds was silently succeeding and
corrupting simulated memory
- if we silently ignore prints outside bounds things are fine
But why are prints outside screen bounds working? We should be accessing
screen data using 'index', and that's checking its bounds.
|
|
|
|
|
| |
I keep forgetting about it. Until, that is, I run gprof. Even if I think
I need a memory profile, a cpu profile is a pretty good proxy.
|
|
|
|
|
|
| |
But still no difference in either memory footprint or in running time.
This will teach me -- for the umpteenth time -- to optimize before
measuring.
|
|
|
|
|
|
| |
Now we can reclaim allocated space. But the API's suspect. I still want
to provide some sort of tree of allocations. For now we'll use this only
to reclaim default-spaces. That's next.
|
|
|