about summary refs log tree commit diff stats
path: root/010vm.cc
Commit message (Collapse)AuthorAgeFilesLines
* 3101 - purge .traces/ dir from repo historyKartik K. Agaram2016-07-051-2/+1
| | | | | | | | | | | | | | | | | | | | | I'd been toying with this idea for some time now given how large the repo had been growing. The final straw was noticing that people cloning the repo were having to wait *5 minutes*! That's not good, particularly for a project with 'tiny' in its description. After purging .traces/ clone time drops to 7 seconds in my tests. Major issue: some commits refer to .traces/ but don't really change anything there. That could get confusing :/ Minor issues: a) I've linked inside commits on GitHub like a half-dozen times online or over email. Those links are now liable to eventually break. (I seem to recall GitHub keeps them around as long as they get used at least once every 60 days, or something like that.) b) Numbering of commits is messed up because some commits only had changes to the .traces/ sub-directory.
* 3083Kartik K. Agaram2016-07-011-3/+8
|
* 3027Kartik K. Agaram2016-06-021-2/+2
|
* 3009Kartik K. Agaram2016-05-251-2/+6
|
* 3008Kartik K. Agaram2016-05-251-2/+2
|
* 2968Kartik K. Agaram2016-05-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | | More reorganization in preparation for implementing recursive abandon(). Refcounts are getting incredibly hairy. I need to juggle containers containing other containers, and containers *pointing* to other containers. For a while I considered getting rid of address_element_info entirely and just going by types for every single update_refcount. But that's definitely more work, and it's unclear that things will be cleaner/shorter/simpler. I haven't measured the speedup, but it seems worth optimizing every pointer copy to make sure we aren't manipulating types at runtime. The key insight now is a) to continue to compute information about nested containers at load time, because that's the common case when updating refcounts, but b) to compute information about *pointed* values at run-time, because that's the uncommon case. As a result, we're going to cheat in the interpreter and use type information at runtime just for abandon(), just because the corresponding task when we get to a compiler will be radically different. It will still be tractable, though.
* 2967Kartik K. Agaram2016-05-171-17/+17
|
* 2931 - be explicit about making copiesKartik K. Agaram2016-05-061-1/+1
|
* 2891 - precompute container sizes and offsetsKartik K. Agaram2016-05-021-0/+3
| | | | | | | It's a bit of a trade-off because we need to store copies of container metadata in each reagent (to support shape-shifting containers), and metadata is not lightweight and will get heavier. But it'll become more unambiguously useful when we switch to a compiler.
* 2882 - warn if programmer overuses transform_all()Kartik K. Agaram2016-04-281-1/+3
| | | | | | | | | | | | | | | | | | | | This continues a line of thought sparked in commit 2831. I spent a while trying to avoid calling size_of() at transform-time, but there's no getting around the fact that translating names to addresses requires knowing how much space they need. This raised the question of what happens if the size of a container changes after a recipe using it is already transformed. I could go down the road of trying to detect such situations and redoing work, but that massively goes against the grain of my original design, which assumed that recipes don't get repeatedly transformed. Even though we call transform_all() in every test, in a non-testing run we should be loading all code and calling transform_all() just once to 'freeze-dry' everything. But even if we don't want to support multiple transforms it's worth checking that they don't occur. This commit does so in just one situation. There are likely others.
* 2856Kartik K. Agaram2016-04-231-1/+1
|
* 2818Kartik K. Agaram2016-03-281-2/+1
|
* 2816Kartik K. Agaram2016-03-271-1/+1
| | | | Move all bounds checks for types and recipes to one place.
* 2803Kartik K. Agaram2016-03-211-8/+28
| | | | | Show more thorough information about instructions in the trace, but keep the original form in error messages.
* 2799 - new approach to undoing changes in testsKartik K. Agaram2016-03-201-0/+30
| | | | | | | | As outlined at the end of 2797. This worked out surprisingly well. Now the snapshotting code touches fewer layers, and it's much better behaved, with less need for special-case logic, particularly inside run_interactive(). 30% slower, but should hopefully not cause any more bugs.
* 2773 - switch to 'int'Kartik K. Agaram2016-03-131-20/+20
| | | | This should eradicate the issue of 2771.
* 2694Kartik K. Agaram2016-02-231-1/+1
|
* 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.
* 2688Kartik K. Agaram2016-02-221-4/+0
|
* 2687Kartik K. Agaram2016-02-221-1/+1
|
* 2681 - drop reagent types from reagent propertiesKartik K. Agaram2016-02-211-43/+81
| | | | | | | | | | | | | | | | | 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.
* 2679Kartik K. Agaram2016-02-201-22/+0
|
* 2678Kartik K. Agaram2016-02-201-1/+2
| | | | | | | 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-201-5/+7
| | | | 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-201-19/+21
| | | | | | | 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-191-2/+2
| | | | It's only for transient debugging.
* 2670 - better names for string conversionsKartik K. Agaram2016-02-191-9/+11
| | | | | | 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-191-13/+15
|
* 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-191-2/+2
|
* 2685Kartik K. Agaram2016-02-191-24/+20
| | | | | | | | | | | | | | | | 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.
* 2667 - redo container data structureKartik K. Agaram2016-02-171-7/+3
| | | | I've been gradually Greenspunning reagents. Just go all the way.
* 2637 - save type names for container elementsKartik K. Agaram2016-02-071-1/+3
|
* 2635Kartik K. Agaram2016-02-061-0/+1
|
* 2617 - better error messagesKartik K. Agaram2016-01-301-1/+2
| | | | | | | | | | | | | | | | | | 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
* 2569Kartik K. Agaram2016-01-181-1/+1
|
* 2567Kartik K. Agaram2016-01-181-2/+7
|
* 2562Kartik K. Agaram2016-01-171-2/+2
| | | | | | | | | | | | We want to use the type 'recipe' for recipe *variables*, because it seems nicer to say `recipe number -> number` rather than recipe-ordinal, etc. To support this we'll allow recipe names to be mentioned without any type. This might make a couple of places in this commit more brittle. I'm dropping error messages, causing them to not happen in some situations. Maybe I should just bite the bullet and require an explicit :recipe-literal. We'll see.
* 2614 - still fixing bugs with missing '['Kartik K. Agaram2015-12-021-4/+11
| | | | | | When skipping past some text (usually whitespace, but also commas and comments) I need to always be aware of whether it's ok to switch to the next line or not.
* 2491Kartik K. Agaram2015-11-281-2/+12
|
* 2487Kartik K. Agaram2015-11-271-28/+0
| | | | | | | | | | | | | | | Ok, now I'm a little happier about our type checking. Type checking lies in three layers: layer 21: checking types, usually at run-time in the VM or just before layer 57: checking type names layer 59: checking type names It's taken me the process of writing this commit to convince myself that all three layers check mappings for literal values in a consistent manner. Layer 21 uses sizes, and layers 57/59 have whitelists, but either way the goal is that number != character != boolean unless mediated through a literal.
* 2483 - to-text can now handle listsKartik K. Agaram2015-11-271-2/+5
| | | | | 'append' also implicitly calls 'to-text' unless there's a better variant.
* 2454Kartik K. Agaram2015-11-171-3/+3
| | | | | | 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-2/+2
| | | | | Starting to leave debug prints around once again, just in case one of them is worth promoting to the trace..
* 2444Kartik K. Agaram2015-11-151-2/+9
| | | | Yet another bugfix as I trace through the last session with Caleb.