about summary refs log tree commit diff stats
path: root/012transform.cc
Commit message (Collapse)AuthorAgeFilesLines
* 4987 - support `browse_trace` tool in SubXKartik Agaram2019-02-251-2/+2
| | | | | | | | | | | | | | | | | | I've extracted it into a separate binary, independent of my Mu prototype. I also cleaned up my tracing layer to be a little nicer. Major improvements: - Realized that incremental tracing really ought to be the default. And to minimize printing traces to screen. - Finally figured out how to combine layers and call stack frames in a single dimension of depth. The answer: optimize for the experience of `browse_trace`. Instructions occupy a range of depths based on their call stack frame, and minor details of an instruction lie one level deeper in each case. Other than that, I spent some time adjusting levels everywhere to make `browse_trace` useful.
* 3760 - force functions to use dependency-injectionKartik K. Agaram2017-03-071-0/+1
| | | | | This is the kind of check I want Mu to be anal about, not whitespace or unused variables.
* 3561Kartik K. Agaram2016-10-221-2/+2
|
* 3555Kartik K. Agaram2016-10-221-1/+1
|
* 3522Kartik K. Agaram2016-10-191-6/+6
|
* 3520Kartik K. Agaram2016-10-181-3/+0
| | | | | | | | Drop a few debug prints. Hopefully now we need never duplicate trace statements and can instead just dump them to screen. I'll soon need the ability to selectively dump traces for a specific label.
* 3437Kartik K. Agaram2016-10-041-1/+0
| | | | | | | | Drop an ancient case of premature optimization: skipping transform for recipes without bodies. These days recipes also have headers that need transforming. Thanks Caleb Couch for running into this issue.
* 3436Kartik K. Agaram2016-10-041-2/+5
|
* 3435Kartik K. Agaram2016-10-041-0/+3
|
* 2882 - warn if programmer overuses transform_all()Kartik K. Agaram2016-04-281-0/+12
| | | | | | | | | | | | | | | | | | | | 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.
* 2815Kartik K. Agaram2016-03-271-1/+1
|
* 2799 - new approach to undoing changes in testsKartik K. Agaram2016-03-201-7/+0
| | | | | | | | 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.
* 2797 - bugfix: transform can create recipesKartik K. Agaram2016-03-191-0/+7
| | | | | | | | | | | | | | | | | | | | | When I started to make channels generic in 2784, I introduced an infinite loop when running until just layer 72. This happens because transform_all() can create new recipes while specializing, and these were getting added to Recently_added_recipes and then deleted. I didn't notice until now because layer 91 was clearing Recently_added_recipes soon after. Solution: make calls to transform_all after calls to load_permanently also clear Recently_added_recipes like load_permanently does. No transforms yet create new types. If they do we'll need to start handling the other Recently_added_* variables as well. I should rethink this whole approach of tracking changes to global state while running tests, and undoing such changes. Ideally I wouldn't need to manually track changes for each global. I should just encapsulate all global state in an object, copy it for each test and delete the copy when I'm done.
* 2796Kartik K. Agaram2016-03-191-5/+0
|
* 2775 - test rewrite-stash transformKartik K. Agaram2016-03-131-0/+5
|
* 2773 - switch to 'int'Kartik K. Agaram2016-03-131-5/+5
| | | | This should eradicate the issue of 2771.
* 2728 - don't ignore /space: while checking typesKartik K. Agaram2016-03-041-0/+6
|
* 2494Kartik K. Agaram2015-11-281-0/+8
| | | | | Some more structure to transforms, and flattening of dependencies between them.
* 2458 - edit/: recipe side free of sandbox errorsKartik K. Agaram2015-11-181-0/+1
| | | | | | | | | This is happening because of our recent generic changes, which trigger some post-processing transforms on all recipes even if we processed them before. We could clear 'interactive' inside 'reload' to avoid this, but random 'run' blocks in scenarios can still pick up errors from sandboxes earlier in a scenario. The right place to clear the 'interactive' recipe is right after we use it, in run_code_end().
* 2393 - redo 2391Kartik K. Agaram2015-11-071-1/+1
| | | | | | | | | | | Got that idea to work with a special-case for 'new'. Requires parsing new's first ingredient, performing the replacement, and then turning it back into a string. I didn't want to replace NEW with ALLOCATE right here, because then it messes with my invariant that transform should never see a naked ALLOCATE. Layer 11 still not working, but everything else is. Let's clean up before we diagnose the new breakage.
* 2392 - undo 2391Kartik K. Agaram2015-11-071-1/+1
| | | | Yup, type ingredients were taking size 1 by default.
* 2391Kartik K. Agaram2015-11-071-1/+1
| | | | | | | | | | | | | No, my idea was abortive. My new plan was to run no transforms for generic recipes, and instead only run them on concrete specializations as they're created. The trouble with this approach is that new contains a type specification in its ingredient which apparently needed to be transformed into an allocate before specialization. But no, how was that working? How was new computing size based on type ingredients? It might have been wrong all along.
* 2382Kartik K. Agaram2015-11-061-0/+1
| | | | Starting to leave commented out prints again out of desperation.
* 2374 - now edit works until layer 8Kartik K. Agaram2015-11-051-4/+0
|
* 2373 - bad bug: instruction was losing /lookupKartik K. Agaram2015-11-051-0/+4
|
* 2364Kartik K. Agaram2015-11-051-0/+10
|
* 2358 - starting to tackle the phase ordering problemKartik K. Agaram2015-11-041-1/+5
| | | | | | | A new externality is starting to make its presence felt. Until I sort this out it's going to be hard to finish making duplex-list generic.
* 2316 - preparing for static dispatchKartik K. Agaram2015-10-291-1/+2
|
* 2311Kartik K. Agaram2015-10-291-0/+4
|
* 2154 - check types only after loading all layersKartik K. Agaram2015-09-051-0/+1
| | | | | Follow-up to 2147, which switched transform_all to only run once, after loading all layers.
* 2095Kartik K. Agaram2015-08-281-2/+0
| | | | | | | | | | | | Finally terminate the experiment of keeping debug prints around. I'm also going to give up on maintaining counts. What we really need is two kinds of tracing: a) For tests, just the domain-specific facts, organized by labels. b) For debugging, just transient dumps to stdout. b) only works if stdout is clean by default. Hmm, I think this means 'stash' should be the transient kind of trace.
* 1702 - experiment: start using 'ordinal' in namesKartik K. Agaram2015-07-041-4/+4
| | | | | | | It comes up pretty early in the codebase, but hopefully won't come up in the mu level until we get to higher-order recipes. Potentially intimidating name, but such prime real estate with no confusing overloadings in other projects!
* 1699 - first-class recipe typesKartik K. Agaram2015-07-031-0/+1
| | | | | It should now be easy to do dynamic dispatch, create higher-order functions, etc.
* 1399 - better 'unknown type' warningsKartik K. Agaram2015-05-181-1/+1
| | | | | | | | Implement warnings for types without definitions without constraining where type definitions must appear. We also eliminate the anti-pattern where a change in layer 10 had its test in layer 11 (commit 1383).
* 1391 - avoid unsigned integersKartik K. Agaram2015-05-171-5/+5
|
* 1387Kartik K. Agaram2015-05-161-2/+2
|
* 1357 - temporarily revert floating-point supportKartik K. Agaram2015-05-121-1/+1
|
* 1356 - snapshot #2: floating point supportKartik K. Agaram2015-05-121-1/+1
| | | | | | | | | | | | | | | I added one test to check that divide can return a float, then hacked at the rippling failures across the entire entire codebase until all tests pass. Now I need to look at the changes I made and see if there's a system to them, identify other places that I missed, and figure out the best way to cover all cases. I also need to show real rather than encoded values in the traces, but I can't use value() inside reagent methods because of the name clash with the member variable. So let's take a snapshot before we attempt any refactoring. This was non-trivial to get right. Even if I convince myself that I've gotten it right, I might back this all out if I can't easily *persuade others* that I've gotten it right.
* 1343Kartik K. Agaram2015-05-111-1/+1
|
* 1323 - keyboard supports backspace and newlineKartik K. Agaram2015-05-101-5/+2
| | | | | | Lots mixed into this commit: some off-by-one errors in display.cc a new transform to translate jump labels that I'd somehow never gotten around to supporting
* 1299 - stop using [] in any vectorKartik K. Agaram2015-05-071-4/+4
| | | | | | | | | Useful check: $ grep "[^ '\"]\[[^\"]" *.cc \ |perl -pwe 's/\Wargv\[|\WTests\[|\Wframe\[|\WMemory\[|\WName\[|\WSurrounding_space\[|\WRecipe\[|\WType\[|\WRecipe_number\[|\WType_number\[|\WBefore_fragments\[|\WAfter_fragments\[//g' \ |perl -pwe 's/\Wargv\[|\WTests\[|\Wframe\[|\WMemory\[|\WName\[|\WSurrounding_space\[|\WRecipe\[|\WType\[|\WRecipe_number\[|\WType_number\[|\WBefore_fragments\[|\WAfter_fragments\[//g' \ |grep '[^ ]\['
* 1276 - make C++ version the defaultKartik K. Agaram2015-05-051-0/+55
I've tried to update the Readme, but there are at least a couple of issues.