about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 2545Kartik K. Agaram2015-12-1534-260/+1182
| | | | update html
* support immutability checks in sandbox/ appKartik K. Agaram2015-12-158-18/+47
|
* three bugs fixedKartik K. Agaram2015-12-158-31/+253
| | | | | | | | | | | | | | | | | - 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.
* bugfix after commit 2612Kartik K. Agaram2015-12-151-0/+21
|
* start working on checking address lifetimeKartik K. Agaram2015-12-151-0/+126
| | | | First some baseline tests that should never trigger warnings.
* start using the new checkKartik K. Agaram2015-12-152-8/+6
| | | | | | | | | | 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.
* improve error messageKartik K. Agaram2015-12-151-8/+16
|
* infect immutability across recipesKartik K. Agaram2015-12-151-2/+47
| | | | | | | | | | | | | | | | | 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.
* next baby step: infect immutability across copiesKartik K. Agaram2015-12-151-15/+54
|
* fix a crash on unknown typeKartik K. Agaram2015-12-151-0/+11
|
* rest of edit/ fixedKartik K. Agaram2015-12-154-8/+8
| | | | No more bugs; phew.
* bugfix: phase orderingKartik K. Agaram2015-12-152-4/+49
|
* layer 3 of edit/ now workingKartik K. Agaram2015-12-154-10/+47
| | | | | 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.
* chessboard.mu now workingKartik K. Agaram2015-12-151-3/+3
|
* layers 1 and 2 of edit/ now workingKartik K. Agaram2015-12-152-5/+5
|
* experiment: treat pure ingredients as immutableKartik K. Agaram2015-12-153-48/+257
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.)
* 2627Kartik K. Agaram2015-12-151-3/+3
|
* 2626Kartik K. Agaram2015-12-151-0/+2
|
* 2625Kartik K. Agaram2015-12-151-4/+1
|
* 2624 - fix all layersKartik K. Agaram2015-12-141-1/+1
|
* 2623 - check 'reply' instructions ahead of timeKartik K. Agaram2015-12-131-38/+58
|
* 2622Kartik K. Agaram2015-12-136-42/+42
|
* 2621Kartik K. Agaram2015-12-081-2/+11
|
* 2620Kartik K. Agaram2015-12-071-1/+4
|
* 2619Kartik K. Agaram2015-12-071-1/+1
|
* 2618Kartik K. Agaram2015-12-071-2/+2
|
* 2617Kartik K. Agaram2015-12-021-1/+0
|
* 2616Kartik K. Agaram2015-12-021-0/+11
| | | | | Can't find a test case where it's reading comments it shouldn't be, so far..
* 2615Kartik K. Agaram2015-12-022-17/+18
| | | | | | 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..
* 2614 - still fixing bugs with missing '['Kartik K. Agaram2015-12-027-41/+49
| | | | | | 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.
* 2613 - stop dying on missing bracketKartik K. Agaram2015-12-021-2/+8
| | | | Thanks Caleb Couch.
* 2612Kartik K. Agaram2015-11-291-9/+9
|
* 2611Kartik K. Agaram2015-11-2961-1101/+1662
|
* 2610Kartik K. Agaram2015-11-291-5/+5
|
* 2609 - run $browse-trace on old runsKartik K. Agaram2015-11-293-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.)
* 2608 - improve errors when static dispatch failsKartik K. Agaram2015-11-293-2/+53
|
* 2607 - resolve some edge cases in static dispatchKartik K. Agaram2015-11-295-16/+101
|
* 2606 - handle cycles inside stashKartik K. Agaram2015-11-294-9/+52
| | | | | | | | | 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.
* 2505 - test_all_layers now passesKartik K. Agaram2015-11-291-15/+2
| | | | | | 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.
* 2504 - support to-text in 'stash'Kartik K. Agaram2015-11-284-8/+72
|
* 2503Kartik K. Agaram2015-11-281-1/+0
|
* 2502Kartik K. Agaram2015-11-283-7/+9
|
* 2501Kartik K. Agaram2015-11-284-8/+7
|
* 2500Kartik K. Agaram2015-11-281-2/+0
|
* 2499 - done reorganizing transformsKartik K. Agaram2015-11-283-7/+9
|
* 2498Kartik K. Agaram2015-11-282-4/+8
| | | | | | Just one tangle of dependencies left in the transforms. Untangling it will require one more region: for transforms modifying types (inside instructions).
* 2497Kartik K. Agaram2015-11-282-4/+4
|
* 2496Kartik K. Agaram2015-11-282-5/+6
|
* 2495Kartik K. Agaram2015-11-282-3/+5
|
* 2494Kartik K. Agaram2015-11-289-24/+39
| | | | | Some more structure to transforms, and flattening of dependencies between them.