about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 2704 - eradicate all mention of warnings from coreKartik K. Agaram2016-02-259-35/+24
|
* 2703Kartik K. Agaram2016-02-257-21/+19
|
* 2702Kartik K. Agaram2016-02-254-36/+35
|
* 2701 - turn some warnings into errorsKartik K. Agaram2016-02-257-37/+37
| | | | | | | I really have only one warning left: when somebody redefines a function. I think I'm going to just turn that into an error as well and drop the notion of warnings altogether. Anytime we find something wrong we stop running the program. This is a place where hygiene is justified.
* 2700 - fail tests on unexpected errors or warningsKartik K. Agaram2016-02-253-4/+21
|
* 2699Kartik K. Agaram2016-02-241-6/+6
|
* 2698Kartik K. Agaram2016-02-241-1/+36
|
* 2697Kartik K. Agaram2016-02-242-6/+12
|
* 2696 - start work on hash 'table' data structureKartik K. Agaram2016-02-242-4/+62
| | | | | | Very cool that I thought I didn't support type ingredients in arbitrary positions in container definitions, but I really did. I just didn't have a test for it, and now I do.
* 2695 - todo for recipe variablesKartik K. Agaram2016-02-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Basically I need to make these tests work: - Test 1: specializing while saving shape-shifting recipe literal recipe f a:address:shared:_elem -> b:address:shared:_elem [ local-scope load-ingredients reply a ] recipe main [ local-scope {x: (recipe (address shared number) -> (address shared number))} <- copy f y:address:shared:number <- new number:type *y <- copy 34 z:address:shared:number <- call x, y $print *z, 10/newline ] - Test 2: passing recipe literal to higher-order recipe recipe g x:address:shared:number, {h: (recipe (address shared number) -> (address shared number))} -> y:address:shared:number [ local-scope load-ingredients y <- call f, x ] recipe main [ local-scope x:address:shared:number <- new number:type *x <- copy 34 y:address:shared:number <- g x, f $print *y, 10/newline ]
* 2694Kartik K. Agaram2016-02-231-1/+1
|
* 2693Kartik K. Agaram2016-02-231-1/+1
| | | | | | I noticed while teaching Ella that when mu encountered a missing recipe it failed to find *any* recipes after that point, leading to a lot of spurious errors. Now fixed.
* 2692 - all memory leaks fixedKartik K. Agaram2016-02-231-1/+3
| | | | | | | | | | To find this I spent some time trying to diagnose when it happened but there was no seeming pattern. I'd ended up with a small single-file .cc and single-file .mu that reproduced one memory leak. Eventually I tried deleting all type_tree and string_tree from it, and lo the leaks vanished. I retried on all of edit (just loading), and the leaks remained gone. At that point I switched tack and started looking at all the core methods of these classes.
* 2691Kartik K. Agaram2016-02-231-2/+0
|
* 2690 - one more memory leakKartik K. Agaram2016-02-221-2/+2
| | | | | | | This is the easy one. The remaining ones are like phantoms popping up and dying at random. One thing I know is that they all have to do with tangling. Always implicated is the line in the tangle layer where instructions are loaded and inserted into After_fragments.
* 2689 - fix a memory leakKartik K. Agaram2016-02-221-1/+1
| | | | | | | That same line that caused me so much grief in 2681! I just ran edit/ through valgrind for the first time, and found more memory leaks breeding while I wasn't looking. That's next.
* 2688Kartik K. Agaram2016-02-223-12/+1
|
* 2687Kartik K. Agaram2016-02-221-1/+1
|
* 2686Kartik K. Agaram2016-02-221-12001/+0
|
* 2685Kartik K. Agaram2016-02-225-7/+6
|
* 2684Kartik K. Agaram2016-02-221-1/+1
|
* 2683Kartik K. Agaram2016-02-212-7/+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.
* 2682Kartik K. Agaram2016-02-211-3/+3
|
* 2681 - drop reagent types from reagent propertiesKartik K. Agaram2016-02-2124-375/+12376
| | | | | | | | | | | | | | | | | 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.
* 2680Kartik K. Agaram2016-02-207-32/+32
| | | | Delete all the [] that has crept in since 2377 in November.
* 2679Kartik K. Agaram2016-02-202-22/+22
|
* 2678Kartik K. Agaram2016-02-2011-90/+92
| | | | | | | 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.
* 2677Kartik K. Agaram2016-02-2010-17/+19
| | | | Include type names in the type tree. Though we aren't using them yet.
* 2676 - start coalescing type and type-name treesKartik K. Agaram2016-02-201-4/+4
|
* 2675 - undo 2674Kartik K. Agaram2016-02-201-21/+19
|
* 2674 - tried to follow s-exps more closelyKartik K. Agaram2016-02-202-19/+24
| | | | | | | 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.
* 2673Kartik K. Agaram2016-02-191-1/+2
|
* 2672Kartik K. Agaram2016-02-191-4/+4
|
* 2671 - never use debug_string() in tracesKartik K. Agaram2016-02-1912-61/+41
| | | | It's only for transient debugging.
* 2670 - better names for string conversionsKartik K. Agaram2016-02-194-17/+19
| | | | | | to_string(): relatively stable fields only; for trace() debug_string(): all fields; for debugging inspect(): for a form that can be parsed back later
* 2689 - consistently use s-exp syntax in tracesKartik K. Agaram2016-02-195-22/+24
|
* 2688Kartik K. Agaram2016-02-191-11/+11
|
* 2687Kartik K. Agaram2016-02-191-111/+116
| | | | | | Move code around to put all string-conversion functions in a single section with a reasonable order, from recipe to instruction to reagent to reagent members.
* 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.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-16 13:47:30 +0000