| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Thanks Caleb Couch.
|
| |
|
|
|
|
|
|
|
|
| |
Reading http://www.jonathanturner.org/2016/01/rust-and-blub-paradox.html,
I realize there's nothing currently stopping mu programs from taking a
unique (non-shared) address into a shared allocation, abandoning the
allocation and being left with an invalid address. No fix for this yet,
but let's try to minimize its effect by limiting lifetimes of unique
addresses. We really should only be using them to write to array or
container elements.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
I still need it in some situations because I have no way to set a
non-zero default for an optional ingredient. Open question..
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Can't find a test case where it's reading comments it shouldn't be, so
far..
|
| |
|
|
|
|
| |
We don't actually need skip_whitespace_AND_comments_BUT_NOT_newline
anywhere except next_word(). Perhaps what I should really do is split
the definition of next_word() into two variants..
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
Thanks Caleb Couch.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
/raw is to express absolute addresses
/unsafe is to sidestep type-checking in test setup
|
| | |
|
| | |
|
| |
|
|
|
|
| |
If a name repeats between ingredients, we raise an error.
If a name repeats across ingredients and products, every call should
share the same name across the corresponding ingredients and products.
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
And it caught a bug: I mean to always update type names and types in
sync.
The last month or so I've been getting reluctantly but inexorably
converted to the need and value of a type system. First I thought I just
need a minimal but rigorous type system to avoid memory corruption and
security issues. Now I think I also want it to be expressive enough to
be able to express what data different phases in a compiler read and
write, and to be able to designate specific fields as 'fully computed'
so that we can statically check that phases wait until their data is
available.
The phase-ordering problem in a compiler is perhaps the canary in the
coal-mine for a more general problem: even small changes can
dramatically explode the state space if they violate assumptions
previously held about the domain. My understanding of when type pointers
are null and not null is immeasurably more nuanced today than it was a
week ago, but I didn't need the nuance until I introduced generic
functions. That initial draft of a hundred lines bumped me up to a much
larger state space. How to make it more obvious when something happens
that is akin to discovering a new continent, or finding oneself
teleported to Jupiter?
Assumptions can be implicit or explicit. Perhaps a delete of an
assertion should be estimated at 1000 LoC of complexity?
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Minor tweak: track all recipe variants.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Forgot to run valgrind again. That triggered some trace cleanup as well.
|
| | |
|
| |
|
|
|
| |
Deduce operation id from name during transform rather than load, so that
earlier transforms have a chance to modify the name.
|
| |
|
|
| |
Forgot to run against valgrind.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
I've been growing lax on white-box testing when it's one of the three
big thrusts of this whole effort. Perhaps it was because I got too
obsessed with keeping traces stable and didn't notice that stable
doesn't mean "not changing". Or perhaps it's because I still don't have
a zoomable trace browser that can parse traces from disk. Or perhaps
$trace-browser is too clunky and discourages me from using it.
Regardless, I need to make the trace useable again before I work much
more on the next few rewriting transforms.
|
| | |
|
|
|
Once a student has gotten used to recipes and ingredients using the
staged 'next-ingredient' approach there's no reason to avoid
conventional function headers. As an added bonus we can now:
a) check that all 'reply' instructions in a recipe are consistent
b) deduce what to reply without needing to say so everytime
c) start thinking about type parameters for recipes (generic functions!)
|