about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 2661 - warn if a reply doesn't match recipe headerKartik K. Agaram2016-02-154-7/+23
| | | | | | | | Thanks Nicolas Léveillé for running up against this bug: https://news.ycombinator.com/item?id=11094837 (Also noticed and fixed several subsidiary issues. This whole aspect doesn't seem fully baked yet.)
* 2660 - check dynamic arrays in exclusive containersKartik K. Agaram2016-02-152-11/+25
| | | | | Also a bugfix: don't cause future parse errors when these checks are triggered.
* 2659 - disallow dynamic arrays in recipesKartik K. Agaram2016-02-151-1/+20
| | | | | | | | | The rule is: every 'local' variable in a recipe must have a fixed size. Arrays can only be directly used in a recipe if their type includes a size. But we haven't been warning about this, and attempts to use array variables could cause silent memory corruption. (Hopefully this is the last hole in our type system.)
* 2658 - warn when containers contain arraysKartik K. Agaram2016-02-152-0/+33
| | | | | | | The rule is: a container type's size must be fixed. Arrays can violate this rule if the array length isn't included in the type. But we haven't been warning about this, and 'new' has been silently turning array elements to be empty.
* 2657 - type-checking for 'merge' instructionsKartik K. Agaram2016-02-155-18/+440
|
* 2656Kartik K. Agaram2016-02-144-4/+4
|
* 2655 - support shape-shifting exclusive containersKartik K. Agaram2016-02-142-2/+32
|
* 2654Kartik K. Agaram2016-02-141-0/+2
|
* 2653Kartik K. Agaram2016-02-141-10/+8
|
* 2652 - fix issue #4Kartik K. Agaram2016-02-132-0/+2
| | | | Thanks chriscool and achikin for reporting this bug.
* Merge pull request #3 from tmsbrg/masterKartik Agaram2016-02-131-2/+2
|\ | | | | move enumerate, tangle dependencies to mu.cc
| * move enumerate, tangle dependencies to mu.ccThomas van der Berg2016-02-131-2/+2
|/
* 2651Kartik K. Agaram2016-02-121-7/+2
|
* 2650Kartik K. Agaram2016-02-121-4/+4
|
* 2649Kartik K. Agaram2016-02-112-1/+3
| | | | More tweaks to the trace after all my debugging.
* 2648Kartik K. Agaram2016-02-112-1/+2
|
* 2647 - more tests while improving commit 2640Kartik K. Agaram2016-02-111-0/+72
| | | | | Very cool that these passed without trouble after the previous change. This is on the right track.
* 2646 - redo static dispatch algorithmKartik K. Agaram2016-02-114-171/+246
| | | | | | | | The old approach of ad hoc boosts and penalties based on various features was repeatedly running into exceptions and bugs. New organization: multiple tiered scores interleaved with tie-breaks. The moment one tier yields one or more candidates, we stop scanning further tiers. Just break ties and return.
* 2645Kartik K. Agaram2016-02-101-1/+1
|
* 2644Kartik K. Agaram2016-02-102-4/+7
| | | | More tweaking of traces as I debug recipe specialization.
* 2643Kartik K. Agaram2016-02-104-6/+5
|
* 2642Kartik K. Agaram2016-02-092-5/+3
|
* 2641Kartik K. Agaram2016-02-081-1/+1
| | | | | Turns out we don't need to threshold non-shape-shifting and shape-shifting variants at different levels to keep all tests passing.
* 2640 - fix some testsKartik K. Agaram2016-02-081-7/+14
| | | | | | | | | | Thanks Caleb Couch for finding this. These tests were breaking only when some other code somewhere has already triggered the specialization of 'append' for numbers. How to test this? Perhaps the right fix is to warn when character variants are used with literals. Or only when there's also a generic variant that could conceivably be specialized for numbers.
* 2639 - convert variables to arrays of 'bytes'Kartik K. Agaram2016-02-071-0/+42
| | | | | | Just this conversion isn't in itself a violation of the type system -- as long as there's no way to convert back. Except there is with 'merge'. Next step is to type-check 'merge'.
* 2638Kartik K. Agaram2016-02-071-0/+0
|
* 2637 - save type names for container elementsKartik K. Agaram2016-02-073-20/+36
|
* 2636Kartik K. Agaram2016-02-061-4/+5
|
* 2635Kartik K. Agaram2016-02-063-0/+7
|
* 2634Kartik K. Agaram2016-02-061-0/+6
|
* 2633Kartik K. Agaram2016-02-061-4/+0
|
* 2632Kartik K. Agaram2016-02-061-12/+13
|
* 2631Kartik K. Agaram2016-02-061-0/+4
|
* 2630Kartik K. Agaram2016-02-061-1/+1
|
* 2629 - starting work on hash tablesKartik K. Agaram2016-02-061-0/+28
|
* 2628Kartik K. Agaram2016-02-051-0/+1
| | | | | Ran into a crash here while loading Caleb's deck-of-war program. Not bothering debugging it..
* 2627 - bitwise operatorsKartik K. Agaram2016-02-041-0/+283
|
* 2626Kartik K. Agaram2016-02-031-0/+80
|
* 2625Kartik K. Agaram2016-02-0224-158/+457
|
* 2624Kartik K. Agaram2016-02-014-30/+46
| | | | Reorganize further to make edit/008-sandbox-test more self-contained.
* 2623 - bugfix: editing sandboxesKartik K. Agaram2016-02-017-12/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you restore 2 sandboxes, the first render was setting response-starting-row-on-screen on both, without ever rendering a response. If the lower sandbox contained a print and rendered the screen instead of the response, the original response-starting-row-on-screen was never reset. If the process of running the sandboxes caused the lower sandbox's title bar to move below the now-stale response-starting-row-on-screen[1], editing the lower sandbox no longer works. [1] (Either because the upper sandbox prints to screen as well (causing the first F4 to move the lower sandbox down by several lines), or because a fresh sandbox is created with several lines before the first F4 is hit.) Current solution: never set response-starting-row-on-screen during reload (or otherwise when there's no response). This is hard to test right now because 'restore' is not a tested interface, and I can't come up with another situation where the response-starting-row-on-screen goes stale. So I'm now trying to keep all changes to response-starting-row-on-screen close together. Another idea is to add a check that the click row lies below the response-starting row *and* above the start of the next sandbox. (But what if there's no next sandbox?) (This bug is really a regression, introduced last Sep in 2163.)
* 2622 - bugfix: left-arrowKartik K. Agaram2016-01-312-6/+156
| | | | Moving back to wrapped line was overflowing the right margin.
* 2621 - bugfix: empty shape-shifting recipesKartik K. Agaram2016-01-301-6/+17
| | | | | My transform pipeline ignores empty recipes, but when I specialized shape-shifting ones I forgot that check.
* 2620Kartik K. Agaram2016-01-304-56/+56
| | | | | I was finding it hard to wrap around the directionality of calls with 'lhs' and 'rhs'. Seems to work better with 'to' and 'from'. Let's see.
* 2619 - actually allow coercing booleans to numbersKartik K. Agaram2016-01-302-4/+22
| | | | | This uncovered a bug where I've been forgetting the directionality of arguments to types_coercible().
* 2618 - support stashing booleansKartik K. Agaram2016-01-301-0/+8
|
* 2617 - better error messagesKartik K. Agaram2016-01-303-2/+50
| | | | | | | | | | | | | | | | | | When we stash a value, mu does several levels of work for us: a) First it inserts instructions above the stash to convert the value to text using to-text-line. b) to-text-line calls to-text. Both are shape-shifting, so multiple levels of specialization happen. To give a good error message, we track the 'stack' of current specializations at the time of the error, and also check if the offending instruction at the top-most level looks like it was inserted while rewriting stash instructions. Manual example (since booleans can't be stashed at the moment): x:boolean <- copy 1/true stash x
* 2616Kartik K. Agaram2016-01-301-0/+1
| | | | Drop yet another source of perturbance in traces.
* 2615Kartik K. Agaram2016-01-301-2/+2
|
* 2614Kartik K. Agaram2016-01-294-9/+9
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-26 19:54:40 +0000