about summary refs log tree commit diff stats
path: root/056recipe_header.cc
Commit message (Collapse)AuthorAgeFilesLines
* 2661 - warn if a reply doesn't match recipe headerKartik K. Agaram2016-02-151-4/+17
| | | | | | | | Thanks Nicolas Léveillé for running up against this bug: https://news.ycombinator.com/item?id=11094837 (Also noticed and fixed several subsidiary issues. This whole aspect doesn't seem fully baked yet.)
* 2643Kartik K. Agaram2016-02-101-2/+2
|
* 2619 - actually allow coercing booleans to numbersKartik K. Agaram2016-01-301-1/+3
| | | | | This uncovered a bug where I've been forgetting the directionality of arguments to types_coercible().
* 2606 - fix crashKartik K. Agaram2016-01-271-1/+1
| | | | Thanks Caleb Couch.
* 2596 - experiment: no unique addresses in callsKartik K. Agaram2016-01-231-0/+38
| | | | | | | | | | Reading http://www.jonathanturner.org/2016/01/rust-and-blub-paradox.html, I realize there's nothing currently stopping mu programs from taking a unique (non-shared) address into a shared allocation, abandoning the allocation and being left with an invalid address. No fix for this yet, but let's try to minimize its effect by limiting lifetimes of unique addresses. We really should only be using them to write to array or container elements.
* 2564Kartik K. Agaram2016-01-181-6/+6
|
* 2562Kartik K. Agaram2016-01-171-6/+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.
* 2559 - stop using 'next-ingredient' explicitlyKartik K. Agaram2016-01-121-2/+4
| | | | | I still need it in some situations because I have no way to set a non-zero default for an optional ingredient. Open question..
* 2557 - type-check most ingredients ahead of timeKartik K. Agaram2016-01-121-2/+83
|
* 2556Kartik K. Agaram2016-01-121-1/+2
|
* 2550Kartik K. Agaram2015-12-281-0/+1
|
* 2616Kartik K. Agaram2015-12-021-0/+11
| | | | | Can't find a test case where it's reading comments it shouldn't be, so far..
* 2615Kartik K. Agaram2015-12-021-13/+2
| | | | | | 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-3/+24
| | | | | | 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.
* 2613 - stop dying on missing bracketKartik K. Agaram2015-12-021-2/+8
| | | | Thanks Caleb Couch.
* 2502Kartik K. Agaram2015-11-281-2/+2
|
* 2501Kartik K. Agaram2015-11-281-1/+1
|
* 2499 - done reorganizing transformsKartik K. Agaram2015-11-281-1/+1
|
* 2497Kartik K. Agaram2015-11-281-3/+3
|
* 2495Kartik K. Agaram2015-11-281-1/+1
|
* 2473 - bad idea to use /raw with multiple intentionsKartik K. Agaram2015-11-221-1/+1
| | | | | /raw is to express absolute addresses /unsafe is to sidestep type-checking in test setup
* 2460 - headers for remaining recipesKartik K. Agaram2015-11-181-3/+1
|
* 2419Kartik K. Agaram2015-11-101-48/+48
|
* 2417 - support mutable ingredients in headersKartik K. Agaram2015-11-101-31/+74
| | | | | | If a name repeats between ingredients, we raise an error. If a name repeats across ingredients and products, every call should share the same name across the corresponding ingredients and products.
* 2413 - another backfilled test for 2391Kartik K. Agaram2015-11-091-0/+8
| | | | This time for the support for 'new' that was added in 2393.
* 2407 - bugfix: parsing recipe headersKartik K. Agaram2015-11-091-2/+26
|
* 2406Kartik K. Agaram2015-11-081-4/+2
| | | | | One new issue: the traces for all tests are perturbed by the .mu files we choose to load.
* 2404 - ah, finally a useful assertionKartik K. Agaram2015-11-081-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | And it caught a bug: I mean to always update type names and types in sync. The last month or so I've been getting reluctantly but inexorably converted to the need and value of a type system. First I thought I just need a minimal but rigorous type system to avoid memory corruption and security issues. Now I think I also want it to be expressive enough to be able to express what data different phases in a compiler read and write, and to be able to designate specific fields as 'fully computed' so that we can statically check that phases wait until their data is available. The phase-ordering problem in a compiler is perhaps the canary in the coal-mine for a more general problem: even small changes can dramatically explode the state space if they violate assumptions previously held about the domain. My understanding of when type pointers are null and not null is immeasurably more nuanced today than it was a week ago, but I didn't need the nuance until I introduced generic functions. That initial draft of a hundred lines bumped me up to a much larger state space. How to make it more obvious when something happens that is akin to discovering a new continent, or finding oneself teleported to Jupiter? Assumptions can be implicit or explicit. Perhaps a delete of an assertion should be estimated at 1000 LoC of complexity?
* 2400 - eliminate last few warningsKartik K. Agaram2015-11-081-4/+7
|
* 2399 - consistent debug_string vocabularyKartik K. Agaram2015-11-081-2/+2
|
* 2383 - new concern: idempotence of transformsKartik K. Agaram2015-11-061-2/+2
| | | | | I'd not paid any attention to it so far, but I need to do so from now on.
* 2382Kartik K. Agaram2015-11-061-0/+2
| | | | Starting to leave commented out prints again out of desperation.
* 2377 - stop using operator[] in mapKartik K. Agaram2015-11-061-10/+10
| | | | | | | | | | | | | | | | 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.
* 2370 - layers 1-4 of edit are backKartik K. Agaram2015-11-051-4/+13
| | | | | | | | | | | | One nice consequence of all my deduction of reply ingredients is that I can insert the same fragment into recipes with different headers, and everything works as long as reply instructions are implicitly deduced. One thing I had to fix to make this work was to move reply-deduction out of rewrite rules and turn it into a first-class transform, so that it happens after tangling. I'm glad to see the back of that hack inside <scroll-down>.
* 2360Kartik K. Agaram2015-11-041-4/+4
| | | | | | | | | More flailing around trying to come up with the right phase ordering. I've tried to narrow down each transform's constraints wrt transforms in previous layers. One issue that keeps biting me is the Type map containing empty records because of stray [] operations. That's gotta be important.
* 2358 - starting to tackle the phase ordering problemKartik K. Agaram2015-11-041-5/+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.
* 2355Kartik K. Agaram2015-11-041-0/+14
|
* 2336Kartik K. Agaram2015-10-311-2/+3
| | | | Minor tweak: track all recipe variants.
* 2335Kartik K. Agaram2015-10-311-1/+1
|
* 2334Kartik K. Agaram2015-10-311-0/+26
|
* 2333Kartik K. Agaram2015-10-311-0/+8
|
* 2328Kartik K. Agaram2015-10-301-3/+19
| | | | Forgot to run valgrind again. That triggered some trace cleanup as well.
* 2322 - deduce types from recipe headerKartik K. Agaram2015-10-291-3/+47
|
* 2321 - more preparations for static dispatchKartik K. Agaram2015-10-291-4/+4
| | | | | Deduce operation id from name during transform rather than load, so that earlier transforms have a chance to modify the name.
* 2318Kartik K. Agaram2015-10-291-1/+1
| | | | Forgot to run against valgrind.
* 2316 - preparing for static dispatchKartik K. Agaram2015-10-291-1/+6
|
* 2312Kartik K. Agaram2015-10-291-1/+1
|
* 2310 - add some more tracingKartik K. Agaram2015-10-291-0/+4
| | | | | | | | | | | 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.
* 2308 - auto-reply on fall-throughKartik K. Agaram2015-10-281-0/+30
|
* 2306 - recipe headersKartik K. Agaram2015-10-281-0/+111
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!)