about summary refs log tree commit diff stats
path: root/011load.cc
Commit message (Collapse)AuthorAgeFilesLines
* 3168 - skip loading recipe 'main' in edit/Kartik K. Agaram2016-08-121-2/+6
| | | | | | | This is part of efforts to allow students to transition gradually from the sandbox to running programs directly on the commandline, writing real scenarios, etc. Running on the commandline requires 'main', but overriding 'main' would mess up edit/ which is itself a Mu program.
* 3120Kartik K. Agaram2016-07-211-4/+2
| | | | | | | | Always show instruction before any transforms in error messages. This is likely going to make some errors unclear because they *need* to show the original instruction. But if we don't have tests for those situations did they ever really work?
* 3101 - purge .traces/ dir from repo historyKartik K. Agaram2016-07-051-1/+0
| | | | | | | | | | | | | | | | | | | | | 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.
* 2990Kartik K. Agaram2016-05-201-1/+1
| | | | | | | | | | Standardize quotes around reagents in error messages. I'm still sure there's issues. For example, the messages when type-checking 'copy'. I'm not putting quotes around them because in layer 60 I end up creating dilated reagents, and then it's a bit much to have quotes and (two kinds of) brackets. But I'm sure I'm doing that somewhere..
* 2803Kartik K. Agaram2016-03-211-28/+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-20/+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.
* 2773 - switch to 'int'Kartik K. Agaram2016-03-131-3/+3
| | | | This should eradicate the issue of 2771.
* 2735 - define recipes using 'def'Kartik K. Agaram2016-03-081-20/+21
| | | | | | | | | | | | 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-9/+9
|
* 2709Kartik K. Agaram2016-02-251-1/+0
| | | | | Only Hide_errors when strictly necessary. In other places let test failures directly show the unexpected error.
* 2704 - eradicate all mention of warnings from coreKartik K. Agaram2016-02-251-9/+9
|
* 2702Kartik K. Agaram2016-02-251-12/+12
|
* 2681 - drop reagent types from reagent propertiesKartik K. Agaram2016-02-211-42/+35
| | | | | | | | | | | | | | | | | 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.
* 2689 - consistently use s-exp syntax in tracesKartik K. Agaram2016-02-191-4/+4
|
* 2686Kartik K. Agaram2016-02-191-1/+1
|
* 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.
* 2648Kartik K. Agaram2016-02-111-0/+1
|
* 2643Kartik K. Agaram2016-02-101-2/+2
|
* 2617 - better error messagesKartik K. Agaram2016-01-301-1/+3
| | | | | | | | | | | | | | | | | | 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
* 2603 - bugfix: defining main with commandline argsKartik K. Agaram2016-01-251-1/+1
| | | | Pretty hacky fix: we simply suppress static dispatch for main.
* 2553 - keep failed specializations from generating spurious errorsKartik K. Agaram2015-12-281-2/+0
| | | | Thanks Caleb Couch.
* three bugs fixedKartik K. Agaram2015-12-151-8/+13
| | | | | | | | | | | | | | | | | - notes bug in edit/ triggers in immutable but not master branch bug triggered by changes to layer 059: we're finding an unspecialized call to 'length' in 'append_6' hard to debug because trace isn't complete just bring out the big hammer: use a new log file length_2 from recipes.mu is not being deleted (bug #1) so reload doesn't switch length to length_2 when variant_already_exists (bug #2) so we end up saving in Recipe for a primitive ordinal so no valid specialization is found for 'length' (bug #3) why doesn't it trigger in a non-interactive scenario? argh, wasn't checking for an empty line at end. ok, confidence restored.
* 2622Kartik K. Agaram2015-12-131-9/+9
|
* 2615Kartik K. Agaram2015-12-021-4/+16
| | | | | | We don't actually need skip_whitespace_AND_comments_BUT_NOT_newline anywhere except next_word(). Perhaps what I should really do is split the definition of next_word() into two variants..
* 2614 - still fixing bugs with missing '['Kartik K. Agaram2015-12-021-27/+9
| | | | | | 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.
* 2454Kartik K. Agaram2015-11-171-13/+13
| | | | | | 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().
* 2407 - bugfix: parsing recipe headersKartik K. Agaram2015-11-091-1/+3
|
* 2384 - tests pass until layer 54Kartik K. Agaram2015-11-071-1/+2
|
* 2379 - further improvements to map operationsKartik K. Agaram2015-11-061-1/+1
| | | | | | | Commands run: $ sed -i 's/\([^. (]*\)\.find(\([^)]*\)) != [^.]*\.end()/contains_key(\1, \2)/g' 0[^0]*cc $ sed -i 's/\([^. (]*\)\.find(\([^)]*\)) == [^.]*\.end()/!contains_key(\1, \2)/g' 0[^0]*cc
* 2378Kartik K. Agaram2015-11-061-1/+1
| | | | | | Now we're starting to run up against the misbehavior introduced by generics: Type tries to insert rows for type ingredients. That is a no-no.
* 2377 - stop using operator[] in mapKartik K. Agaram2015-11-061-7/+7
| | | | | | | | | | | | | | | | 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.
* 2334Kartik K. Agaram2015-10-311-0/+2
|
* 2323 - static dispatch!Kartik K. Agaram2015-10-291-1/+1
|
* 2321 - more preparations for static dispatchKartik K. Agaram2015-10-291-9/+2
| | | | | Deduce operation id from name during transform rather than load, so that earlier transforms have a chance to modify the name.
* 2316 - preparing for static dispatchKartik K. Agaram2015-10-291-14/+15
|
* 2314 - final tweaks to traceKartik K. Agaram2015-10-291-1/+1
| | | | | | | | I checked these commands: $ mu x.mu $ grep "===" .traces/interactive $ grep "===\|---" .traces/interactive
* 2310 - add some more tracingKartik K. Agaram2015-10-291-4/+7
| | | | | | | | | | | 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.
* 2306 - recipe headersKartik K. Agaram2015-10-281-8/+7
| | | | | | | | | | Once a student has gotten used to recipes and ingredients using the staged 'next-ingredient' approach there's no reason to avoid conventional function headers. As an added bonus we can now: a) check that all 'reply' instructions in a recipe are consistent b) deduce what to reply without needing to say so everytime c) start thinking about type parameters for recipes (generic functions!)
* 2293Kartik K. Agaram2015-10-271-3/+3
|
* 2287 - new lexing rulesKartik K. Agaram2015-10-271-5/+14
| | | | | Now we always consider words to be terminated at () and {}. We also always skip commas.
* 2286Kartik K. Agaram2015-10-271-1/+2
|
* 2285Kartik K. Agaram2015-10-261-2/+3
| | | | Still trying to come up with clean lexing rules.
* 2283 - represent each /property as a treeKartik K. Agaram2015-10-261-7/+2
|
* 2282Kartik K. Agaram2015-10-261-28/+28
| | | | | Switch format for tracing reagents in preparation for trees rather than arrays of properties.
* 2277 - reagents now have a tree of typesKartik K. Agaram2015-10-251-3/+4
|
* 2276Kartik K. Agaram2015-10-251-1/+1
|
* 2274Kartik K. Agaram2015-10-251-3/+0
|
* 2273 - start expanding the type systemKartik K. Agaram2015-10-251-6/+0
| | | | | | | | | | | | | | Current plan: parsing {x: foo, y: bar} syntax for reagents parsing s-expr syntax for properties supporting reverse instructions (<-) parsing s-expr syntax for recipe headers (recipe number number -> number) static dispatch generic functions type-checking higher-order functions type of delimited continuations? need more type information First step is done, and the second partially so.
* 2258 - separate warnings from errorsKartik K. Agaram2015-10-061-11/+11
| | | | | | | At the lowest level I'm reluctantly starting to see the need for errors that stop the program in its tracks. Only way to avoid memory corruption and security issues. But beyond that core I still want to be as lenient as possible at higher levels of abstraction.
* 2193Kartik K. Agaram2015-09-141-2/+2
|