| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | 2707 | Kartik K. Agaram | 2016-02-25 | 1 | -5/+0 |
| | | |||||
| * | 2681 - drop reagent types from reagent properties | Kartik K. Agaram | 2016-02-21 | 1 | -0/+5 |
| | | | | | | | | | | | | | | | | | | 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. | ||||
| * | 2576 - distinguish allocated addresses from others | Kartik K. Agaram | 2016-01-19 | 1 | -4/+4 |
| | | | | | | | | | | | | | | | | | This is the one major refinement on the C programming model I'm planning to introduce in mu. Instead of Rust's menagerie of pointer types and static checking, I want to introduce just one new type, and use it to perform ref-counting at runtime. So far all we're doing is updating new's interface. The actual ref-counting implementation is next. One implication: I might sometimes need duplicate implementations for a recipe with allocated vs vanilla addresses of the same type. So far it seems I can get away with just always passing in allocated addresses; the situations when you want to pass an unallocated address to a recipe should be few and far between. | ||||
| * | 2430 - make room for more transforms | Kartik K. Agaram | 2015-11-13 | 1 | -0/+25 |