about summary refs log tree commit diff stats
path: root/020run.cc
Commit message (Collapse)AuthorAgeFilesLines
* 2973 - reclaim refcounts for local scopes againKartik K. Agaram2016-05-181-4/+3
| | | | | | More thorough redo of commit 2767 (Mar 12), which was undone in commit 2810 (Mar 24). It's been a long slog. Next step: write a bunch of mu code in the edit/ app in search of bugs.
* 2932Kartik K. Agaram2016-05-061-6/+6
| | | | | | | More consistent labeling of waypoints. Use types only when you need to distinguish between function overloadings. Otherwise just use variable names unless it's truly not apparent what they are (like that the result is a recipe in "End Rewrite Instruction").
* 2931 - be explicit about making copiesKartik K. Agaram2016-05-061-4/+6
|
* 2882 - warn if programmer overuses transform_all()Kartik K. Agaram2016-04-281-0/+1
| | | | | | | | | | | | | | | | | | | | 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.
* 2864 - replace all address:shared with just addressKartik K. Agaram2016-04-241-1/+1
| | | | | | | Now that we no longer have non-shared addresses, we can just always track refcounts for all addresses. Phew!
* 2862Kartik K. Agaram2016-04-241-1/+1
| | | | | Layers 0-29 are now a complete rudimentary platform except for pointers and indirection.
* 2827 - start replacing 'get-address' with 'put'Kartik K. Agaram2016-04-101-0/+1
| | | | | | | Current plan: - get rid of get-address and index-address, and therefore any address that is not address:shared - rename address:shared to just 'shared'
* 2816Kartik K. Agaram2016-03-271-1/+0
| | | | Move all bounds checks for types and recipes to one place.
* 2803Kartik K. Agaram2016-03-211-11/+7
| | | | | Show more thorough information about instructions in the trace, but keep the original form in error messages.
* 2800 - remove a gotcha when writing testsKartik K. Agaram2016-03-201-1/+6
| | | | | | | | | Several times now I've wasted time tracking down a failing test only to eventually remember that order of definition matters in tests even though it doesn't elsewhere -- I've been having tests implicitly start running the first function defined in them. Now I stop doing that if a test defines a function called 'main', and just start the test at main instead.
* 2799 - new approach to undoing changes in testsKartik K. Agaram2016-03-201-11/+8
| | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | | | | | | | 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.
* 2792Kartik K. Agaram2016-03-191-0/+1
|
* 2773 - switch to 'int'Kartik K. Agaram2016-03-131-16/+16
| | | | This should eradicate the issue of 2771.
* 2772 - fix all layersKartik K. Agaram2016-03-131-0/+5
|
* 2765Kartik K. Agaram2016-03-121-9/+9
| | | | | Get rid of a local variable that was only serving to render unreadable the code for reclaiming allocated memory.
* 2762Kartik K. Agaram2016-03-121-1/+1
|
* 2735 - define recipes using 'def'Kartik K. Agaram2016-03-081-10/+10
| | | | | | | | | | | | I'm dropping all mention of 'recipe' terminology from the Readme. That way I hope to avoid further bike-shedding discussions while I very slowly decide on the right terminology with my students. I could be smarter in my error messages and use 'recipe' when code uses it and 'function' otherwise. But what about other words like ingredient? It would all add complexity that I'm not yet sure is worthwhile. But I do want separate experiences for veteran programmers reading about Mu on github and for people learning programming using Mu.
* 2712Kartik K. Agaram2016-02-261-5/+5
|
* 2707Kartik K. Agaram2016-02-251-1/+0
|
* 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.
* 2685Kartik K. Agaram2016-02-191-4/+4
| | | | | | | | | | | | | | | | 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.
* 2663Kartik K. Agaram2016-02-161-6/+1
|
* 2649Kartik K. Agaram2016-02-111-0/+2
| | | | More tweaks to the trace after all my debugging.
* 2610 - warn when recipes don't use default-spaceKartik K. Agaram2016-01-271-0/+2
| | | | Somehow this never transferred over from the Arc version until now.
* 2609 - reuse test-recipe variables in sandbox/ testsKartik K. Agaram2016-01-271-0/+1
| | | | | | | | I'd feared that the refcount errors in the previous commit meant there was a bug in my ref-counting, so I temporarily used new variables rather than reusing existing ones. But it turns out the one remaining place memory corruption can happen is when recipes don't use default-scope and so end up sharing memory. Don't I have a warning for this?
* 2583 - start maintaining refcountsKartik K. Agaram2016-01-211-1/+3
| | | | | | | | | | | | Also start auto-abandoning addresses when their refcount returns to 0. I'm mixing this auto-abandon support with my earlier/hackier support for automatically abandoning default-space created by 'local-scope'. We need to flesh out the story for automatically reclaiming memory using C++-style destructors. But that's a value-add. Memory corruption is far more important to avoid than memory *leaks*.
* 2579Kartik K. Agaram2016-01-201-0/+1
| | | | Separate core mu tests from those loaded from the commandline.
* 2557 - type-check most ingredients ahead of timeKartik K. Agaram2016-01-121-0/+1
|
* 2622Kartik K. Agaram2015-12-131-1/+1
|
* 2478Kartik K. Agaram2015-11-271-3/+3
|
* 2461Kartik K. Agaram2015-11-191-4/+2
|
* 2416Kartik K. Agaram2015-11-101-1/+1
|
* 2406Kartik K. Agaram2015-11-081-0/+4
| | | | | One new issue: the traces for all tests are perturbed by the .mu files we choose to load.
* 2398Kartik K. Agaram2015-11-081-2/+2
|
* 2396 - edit working again!!Kartik K. Agaram2015-11-081-2/+2
| | | | | | | | | | | Still some spurious warnings. This was an insane experience building out generics. Time to reflect. Where did I go wrong? How did I end up writing no tests? Let's take some time and go over the last 50 commits with a fine-tooth comb. Generics seems to be the feature that has moved mu from a VM project to a compiler project.
* 2390 - undo 2389Kartik K. Agaram2015-11-071-2/+2
| | | | Ooh, I think I see a solution.
* 2389Kartik K. Agaram2015-11-071-2/+2
| | | | | | | | Now we're back to trying to rerunning idempotent transforms on specialized recipes. Still doesn't work, but at least we don't see different results depending on whether the trace is enabled inside the test or right at the start. That got fixed by the more disciplined insertion into maps, looks like.
* 2388 - final layer of edit/ loaded successfullyKartik K. Agaram2015-11-071-0/+1
|
* 2377 - stop using operator[] in mapKartik K. Agaram2015-11-061-9/+9
| | | | | | | | | | | | | | | | I'm still seeing all sorts of failures in turning on layer 11 of edit/, so I'm backing away and nailing down every culprit I run into. First up: stop accidentally inserting empty objects into maps during lookups. Commands run: $ sed -i 's/\(Recipe_ordinal\|Recipe\|Type_ordinal\|Type\|Memory\)\[\([^]]*\)\] = \(.*\);/put(\1, \2, \3);/' 0[1-9]* $ vi 075scenario_console.cc # manually fix up Memory[Memory[CONSOLE]] $ sed -i 's/\(Memory\)\[\([^]]*\)\]/get_or_insert(\1, \2)/' 0[1-9]* $ sed -i 's/\(Recipe_ordinal\|Type_ordinal\)\[\([^]]*\)\]/get(\1, \2)/' 0[1-9]* $ sed -i 's/\(Recipe\|Type\)\[\([^]]*\)\]/get(\1, \2)/' 0[1-9]* Now mu dies pretty quickly because of all the places I try to lookup a missing value.
* 2321 - more preparations for static dispatchKartik K. Agaram2015-10-291-5/+0
| | | | | Deduce operation id from name during transform rather than load, so that earlier transforms have a chance to modify the name.
* 2315Kartik K. Agaram2015-10-291-2/+2
|
* 2314 - final tweaks to traceKartik K. Agaram2015-10-291-0/+1
| | | | | | | | I checked these commands: $ mu x.mu $ grep "===" .traces/interactive $ grep "===\|---" .traces/interactive
* 2313Kartik K. Agaram2015-10-291-2/+2
|
* 2310 - add some more tracingKartik K. Agaram2015-10-291-0/+3
| | | | | | | | | | | I've been growing lax on white-box testing when it's one of the three big thrusts of this whole effort. Perhaps it was because I got too obsessed with keeping traces stable and didn't notice that stable doesn't mean "not changing". Or perhaps it's because I still don't have a zoomable trace browser that can parse traces from disk. Or perhaps $trace-browser is too clunky and discourages me from using it. Regardless, I need to make the trace useable again before I work much more on the next few rewriting transforms.
* 2301 - test_all_layers fixesKartik K. Agaram2015-10-281-2/+9
|
* 2277 - reagents now have a tree of typesKartik K. Agaram2015-10-251-8/+11
|
* 2272Kartik K. Agaram2015-10-191-1/+0
|
* 2271 - bugfix: traces cross-contaminating errorsKartik K. Agaram2015-10-191-1/+1
| | | | | | | | | | | | | | | | | | There were several places where we push a call on to a routine without incrementing call-stack depth, which was used to compute the depth at which to trace an instruction. So sometimes you ended up one depth lower than you started a call with. Do this enough times and instructions that should be traced at level 100 end up at level 0 and pop up as errors. Solution: since call-stack depth is only used for tracing, include it in the trace stream and make sure we reset it along with the trace stream. Then catch all places where we forget to increment call-stack depth and make sure we catch such places in the future. When I first ran into this with Caleb I thought there must be some way that we're writing some output into the warnings result. I didn't recognize that the spurious output as part of the trace, just at the wrong level.