about summary refs log tree commit diff stats
path: root/058shape_shifting_container.cc
Commit message (Collapse)AuthorAgeFilesLines
* 2720 - hash table teetering but aliveKartik K. Agaram2016-02-281-11/+61
| | | | More bugs fixed in generics to make this work.
* 2712Kartik K. Agaram2016-02-261-6/+6
|
* 2709Kartik K. Agaram2016-02-251-6/+0
| | | | | Only Hide_errors when strictly necessary. In other places let test failures directly show the unexpected error.
* 2683Kartik K. Agaram2016-02-211-6/+0
| | | | | | Ok, we don't need that check after all, because the type_ingredient_names.empty() check earlier in the layer prevents it from ever triggering.
* 2681 - drop reagent types from reagent propertiesKartik K. Agaram2016-02-211-33/+20
| | | | | | | | | | | | | | | | | All my attempts at staging this change failed with this humongous commit that took all day and involved debugging three monstrous bugs. Two of the bugs had to do with forgetting to check the type name in the implementation of shape-shifting recipes. Bug #2 in particular would cause core tests in layer 59 to fail -- only when I loaded up edit/! It got me to just hack directly on mu.cc until I figured out the cause (snapshot saved in mu.cc.modified). The problem turned out to be that I accidentally saved a type ingredient in the Type table during specialization. Now I know that that can be very bad. I've checked the traces for any stray type numbers (rather than names). I also found what might be a bug from last November (labeled TODO), but we'll verify after this commit.
* 2678Kartik K. Agaram2016-02-201-35/+37
| | | | | | | Start using type names from the type tree rather than the property tree in most places. Hopefully the only occurrences of 'properties.at(0).second' left are ones where we're managing it. Next we can stop writing to it.
* 2674 - tried to follow s-exps more closelyKartik K. Agaram2016-02-201-0/+3
| | | | | | | But I realize that this won't actually streamline replace_type_ingredients(), which needs that 'if (curr->left) curr = curr->left' dance for an unrelated reason. So there's no justification for entering into this big refactoring.
* 2671 - never use debug_string() in tracesKartik K. Agaram2016-02-191-5/+5
| | | | It's only for transient debugging.
* 2683Kartik K. Agaram2016-02-191-57/+53
| | | | | | | | | | | | | 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-191-26/+26
| | | | Memory leaks fixed.
* 2679 - all tests passing againKartik K. Agaram2016-02-191-58/+43
| | | | | | | | | | 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-181-11/+144
| | | | | | | | | | | 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.
* 2667 - redo container data structureKartik K. Agaram2016-02-171-6/+6
| | | | I've been gradually Greenspunning reagents. Just go all the way.
* 2657 - type-checking for 'merge' instructionsKartik K. Agaram2016-02-151-12/+120
|
* 2655 - support shape-shifting exclusive containersKartik K. Agaram2016-02-141-0/+29
|
* 2654Kartik K. Agaram2016-02-141-0/+2
|
* 2637 - save type names for container elementsKartik K. Agaram2016-02-071-5/+3
|
* 2457Kartik K. Agaram2015-11-171-7/+1
|
* 2454Kartik K. Agaram2015-11-171-1/+1
| | | | | | Another gotcha uncovered in the process of sorting out the previous commit: I keep using eof() but forgetting that there are two other states an istream can get into. Just never use eof().
* 2445 - dispatch between shape-shifting variantsKartik K. Agaram2015-11-151-1/+1
| | | | | Starting to leave debug prints around once again, just in case one of them is worth promoting to the trace..
* 2424Kartik K. Agaram2015-11-101-8/+3
|
* 2421 - 'generic' => 'shape-shifting'Kartik K. Agaram2015-11-101-0/+256
More evocative, less jargony.