about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 2686Kartik K. Agaram2016-02-192-3/+3
|
* 2685Kartik K. Agaram2016-02-1935-166/+162
| | | | | | | | | | | | | | | | Stack of plans for cleaning up replace_type_ingredients() and a couple of other things, from main problem to subproblems: include type names in the type_tree rather than in the separate properties vector make type_tree and string_tree real cons cells, with separate leaf nodes redo the vocabulary for dumping various objects: do we really need to_string and debug_string? can we have a version with *all* information? can we have to_string not call debug_string? This commit nibbles at the edges of the final task, switching from member method syntax to global function like almost everything else. I'm mostly using methods just for STL in this project.
* 2684Kartik K. Agaram2016-02-198-4597/+0
| | | | Cleanup.
* 2683Kartik K. Agaram2016-02-199-57/+4650
| | | | | | | | | | | | | Attempts at improving the superficial looks of replace_type_ingredients(). These don't change the underlying complexity, but perhaps they help gain confidence that all cases have been covered. There's a mini version-history of prior attempts in tmp directories. But really, the ugliness and duplication here stems from earlier design choices: a) Keeping type ordinals and type names in separate trees. b) Even further back, choosing to duplicate types at properties[0].
* 2682Kartik K. Agaram2016-02-191-0/+13
| | | | | | | | | New test after yesterday's changes already passing, which helps me gain some confidence. There's some redundancy in the shape_shifting_container layer. I'm probably testing the same things at the level of element_type(), MERGE, and GET..
* 2681Kartik K. Agaram2016-02-191-1/+1
|
* 2680Kartik K. Agaram2016-02-192-27/+27
| | | | Memory leaks fixed.
* 2679 - all tests passing againKartik K. Agaram2016-02-193-64/+55
| | | | | | | | | | Still not done, though: a) There's a few memory leaks to track down, including one in hash from 2668. b) replace_type_ingredients has gotten *even* uglier. I need to rethink it.
* 2678Kartik K. Agaram2016-02-191-0/+1
| | | | Now I've fixed the type-checker, but it fails while running.
* 2677Kartik K. Agaram2016-02-191-11/+30
| | | | | Getting warmer. The unit tests for element_type now work, and the larger test too seems to get further.
* 2676Kartik K. Agaram2016-02-191-21/+24
| | | | Inline nth_type and nth_type_name.
* 2675Kartik K. Agaram2016-02-181-10/+8
| | | | | Make nth_type non-recursive in advance of hoisting the call into the caller.
* 2674Kartik K. Agaram2016-02-181-1/+7
| | | | | | | | | | Make it explicit that I don't currently intend to further replace type ingredients inside replacements. That might well make sense, but I've not thought up any use cases or tests for it, and it seems excessive at the moment. And when I find bugs I keep wondering if the repeated replace might be the problem. No longer.
* 2673 - renameKartik K. Agaram2016-02-181-8/+8
|
* 2672 - no, that test should be considered failingKartik K. Agaram2016-02-181-2/+20
| | | | | Also exercise the breaking part in a couple of the unit tests for replace_type_ingredient. Now we need to fix all three.
* 2671Kartik K. Agaram2016-02-181-8/+29
| | | | | | Fix the pending test while trying to fix the warning about 'merge'. Warning still present.
* 2670 - improvements to genericsKartik K. Agaram2016-02-182-11/+146
| | | | | | | | | | | Eliminated a few holes, gained more clarity on the shape of others. Maybe I was sleep-deprived, but this was really hard until I wrote a few unit tests directly on replace_type_ingredient. Still one flaw remaining: the type-checker isn't smart enough to handle 'merge' for all the new cases. Tests pass since we don't use those features outside C++ tests yet.
* 2669Kartik K. Agaram2016-02-171-0/+1
|
* 2668 - add an escape hatch for 'hash'Kartik K. Agaram2016-02-171-0/+21
| | | | | | | | If you don't want a field of a container to be included in its hash, use the /ignore-for-hash property. This property only works for containers, not exclusive-containers or arrays. Mu will warn if you misuse it.
* 2667 - redo container data structureKartik K. Agaram2016-02-177-85/+57
| | | | I've been gradually Greenspunning reagents. Just go all the way.
* 2666Kartik K. Agaram2016-02-171-1/+1
|
* 2665Kartik K. Agaram2016-02-173-15/+6
|
* 2664 - 'hash' any typeKartik K. Agaram2016-02-161-3/+339
| | | | | | This is smart enough to only look at data and ignores internal book-keeping like addresses, refcounts and floating-point details. Though the last is not ideal yet.
* 2663Kartik K. Agaram2016-02-161-6/+1
|
* 2662 - rewrite 'hash' in C++Kartik K. Agaram2016-02-152-28/+36
| | | | | | | | | Since it needs specialized non-overflowing types like unsigned long long, my plan is to eventually write it in straight machine code using Mu primitives to make that a slightly nicer process. Hopefully we'll need to deal with machine types only for a tiny set of crucial primitives and it won't be too painful to drop down to machine code for them.
* 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'.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-07-02 05:50:31 +0000