| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
update html
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- notes
bug in edit/ triggers in immutable but not master branch
bug triggered by changes to layer 059: we're finding an unspecialized call to 'length' in 'append_6'
hard to debug because trace isn't complete
just bring out the big hammer: use a new log file
length_2 from recipes.mu is not being deleted (bug #1)
so reload doesn't switch length to length_2 when variant_already_exists (bug #2)
so we end up saving in Recipe for a primitive ordinal
so no valid specialization is found for 'length' (bug #3)
why doesn't it trigger in a non-interactive scenario?
argh, wasn't checking for an empty line at end. ok, confidence restored.
|
| | |
|
| |
|
|
| |
First some baseline tests that should never trigger warnings.
|
| |
|
|
|
|
|
|
|
|
| |
I wasn't seeing errors because I wasn't using /contained-in in products
yet. But it seems to work fine even after.
One reason this isn't an invasive change is that it's opt-in. Most of
the time it isn't triggered. You have to add the /contained-in check to
trigger a check. But that's just like regular const checks in other
languages: if you don't specify immutability you get no checks.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a product is contained-in some ingredient, then the caller will check
the product for mutations as well. For example, consider this
linked-list operation:
b:address:list:number <- next a:address:list:number
If 'a' is immutable in the surrounding recipe, you probably want 'b' to
be immutable as well. You can achieve this by giving 'next' the
following header (ignoring shape-shifting):
recipe next a:address:list:number -> b:address:list:number/contained-in:a
This is the theory, anyway. Rather to my surprise, this doesn't trigger
any issues with existing code. That's probably too good to be true.
|
| | |
|
| | |
|
| |
|
|
| |
No more bugs; phew.
|
| | |
|
| |
|
|
|
| |
Now I complain before running if a call somewhere doesn't line up with
its ingredients, or if no specialization can be made to match it.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This isn't complete yet:
a) If you copy a variable the copy is not checked for mutations.
b) /contained-in might be a hack. It's needed because sometimes I want
to pass in two pointers to a data structure, say for deleting something
from a list. Both are conceptually the same structure, so it's
unnecessary for both to be products as well. There's also technical
reasons you *can't* return both, because if you pass in the same
variable to both ingredients (say you want to remove the first element
of a list), the products now must write to the same variable as well
(thanks to our earlier /same-as-ingredient constraint), and what value
gets written last is not something we want to be thinking about.
c) Even if we stick with /contained-in, it's ambiguous. I'm using it
sometimes to say "a belongs to b", sometimes to say "a _will_ belong to
b after the recipe returns. Perhaps that distinction doesn't matter.
We'll see.
d) Should we be encouraged to say ingredients are contained in products?
At the moment 'push' works only because of mu's incomplete analysis.
Once we fix a) above, it's unclear what the right header should be.
e) edit/ isn't close to working yet.
(No more commit numbers since I'm now starting a branch, and can't rely
on a stable ordering as I rebase. For the same reason I'm not including
the changes to .traces/, to minimize merge conflicts.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is long overdue. Let's see if it gets me using traces more during
debugging.
Though perhaps I'm being too persnickety. These are all valid ways to
debug programs:
a) print directly to screen
b) log, and then dump the log on some condition
c) temporarily print selected log statements directly to screen
d) log, and then browse the log using the zoom interface
For a) to work we need to normally keep prints empty.
For b) to work the log needs to be of some manageable size, where it's
tractable to find interesting features.
d) is the ultimate weapon, but might be slow because it's interactive
c) seems like the ugly case. Should I be trying to avoid it altogether?
Let's try, and see if d) is useable when we want to do c). For simple
cases it's still totally acceptable to just print. If the prints get too
complex to parse, then we move to the zoom interface. Hopefully it'll be
easier because we have to spend less time getting the prints just so.
(Independent of all this, often the best way to make a log manageable so
any of the approaches works: distill the bad behavior down to a test.
But that leads to chicken-and-egg situations where you need to first
understand before you can distill.)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The idea is that to-text-line should truncate blindly past some
threshold, even if to-text isn't smart enough to avoid infinite loops.
Maybe I should define a 'truncating buffer' which stops once it fills
up. That would be an easy way to eliminate all infinite loops in
to-text-line.
|
| |
|
|
|
|
| |
Drop the display-list test because it's subsumed by the stash-on-list
test right below, which doesn't require the notion of a screen from
later layers.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Just one tangle of dependencies left in the transforms. Untangling it
will require one more region: for transforms modifying types (inside
instructions).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Some more structure to transforms, and flattening of dependencies
between them.
|