| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
We don't yet actually maintain the refcount. That's next.
Hardest part of this was debugging the assume-console scenarios in layer
85. That took some detailed manual diffing of traces (because the output
of diff was no good).
New tracing added in this commit add 8% to .traces LoC. Commented out
trace() calls (used during debugging) make that 45%.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the one major refinement on the C programming model I'm planning
to introduce in mu. Instead of Rust's menagerie of pointer types and
static checking, I want to introduce just one new type, and use it to
perform ref-counting at runtime.
So far all we're doing is updating new's interface. The actual
ref-counting implementation is next.
One implication: I might sometimes need duplicate implementations for a
recipe with allocated vs vanilla addresses of the same type. So far it
seems I can get away with just always passing in allocated addresses;
the situations when you want to pass an unallocated address to a recipe
should be few and far between.
|
| | |
|
| |
|
|
| |
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
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Thanks Caleb Couch.
|
| |
|
|
|
|
|
| |
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?
|
| |
|
|
|
|
|
|
|
| |
Front-loads it a bit more than I'd like, but the payoff is that other
recipes will now be able to describe the type checks right next to their
operation.
I'm also introducing a new use of /raw with literals to indicate unsafe
typecasts.
|
| | |
|
| |
|
|
|
| |
That way we only have to check each static instruction once, rather than
every time it runs.
|
| |
|
|
|
|
|
|
|
|
|
| |
Turns out the default format for printing floating point numbers is
neither 'scientific' nor 'fixed' even though those are the only two
options offered. Reading the C++ standard I found out that the default
(modulo locale changes) is basically the same as the printf "%g" format.
And "%g" is basically the shorter of:
a) %f with trailing zeros trimmed
b) %e
So we'll just do %f and trim trailing zeros.
|
| |
|
|
| |
Adjust spaces in 'stash'.
|
| |
|
|
| |
Minor issue in building until just layer 32.
|
| | |
|
| |
|
|
|
| |
Not strictly necessary, but it might help me stage the introduction of
arrays and 'new'.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
Standardize test names.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
That should avoid many issues with typos in names.
|
| |
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
I was counting locations when I should have been counting elements.
|
| |
|
|
|
| |
Current model: you click on something to put it on the editor at the top
of the column. Worth a shot.
|
| |
|
|
|
|
|
| |
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!
|
| | |
|
| | |
|
| | |
|
| | |
|