about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 2355Kartik K. Agaram2015-11-041-0/+14
|
* 2354Kartik K. Agaram2015-11-042-3/+41
|
* 2353 - now 'list' type can be fully generic!Kartik K. Agaram2015-11-041-31/+34
|
* 2352Kartik K. Agaram2015-11-042-3/+4
|
* 2351 - support arbitrary type trees in 'new'Kartik K. Agaram2015-11-042-51/+77
| | | | In the process we also convert types to sizes before we start running.
* 2350Kartik K. Agaram2015-11-041-1/+7
| | | | Now it's not just tests that define recipe variants.
* 2349Kartik K. Agaram2015-11-021-19/+0
|
* 2348Kartik K. Agaram2015-11-021-5/+5
|
* 2347Kartik K. Agaram2015-11-021-0/+2
|
* 2346 - typoKartik K. Agaram2015-11-011-1/+1
| | | | No test, but discovered when fixing list.mu.
* 2345Kartik K. Agaram2015-11-011-2/+2
|
* 2344Kartik K. Agaram2015-11-011-0/+1
|
* 2343Kartik K. Agaram2015-11-011-0/+2
| | | | Clean up specialized recipes more thoroughly.
* 2342 - generalize generic recipesKartik K. Agaram2015-11-012-28/+108
| | | | | Support for type ingredients anywhere. I've been working on this since commit 2331.
* 2341 - fill in gaps in generic containersKartik K. Agaram2015-11-012-11/+61
|
* 2340Kartik K. Agaram2015-11-011-7/+5
|
* 2339 - don't let dump_types modify TypeKartik K. Agaram2015-11-012-3/+13
|
* 2338Kartik K. Agaram2015-11-011-12/+12
|
* 2337Kartik K. Agaram2015-11-011-0/+1
|
* 2336Kartik K. Agaram2015-10-312-10/+21
| | | | Minor tweak: track all recipe variants.
* 2335Kartik K. Agaram2015-10-311-1/+1
|
* 2334Kartik K. Agaram2015-10-314-4/+31
|
* 2333Kartik K. Agaram2015-10-311-0/+8
|
* 2332Kartik K. Agaram2015-10-311-1/+21
|
* 2331 - generic recipe: first passing testKartik K. Agaram2015-10-312-0/+145
|
* 2330 - support generic containers in 'get'Kartik K. Agaram2015-10-301-4/+53
|
* 2329 - hacky start to generic containersKartik K. Agaram2015-10-302-0/+101
|
* 2328Kartik K. Agaram2015-10-301-3/+19
| | | | Forgot to run valgrind again. That triggered some trace cleanup as well.
* 2327Kartik K. Agaram2015-10-301-4/+1
|
* 2326Kartik K. Agaram2015-10-301-8/+8
|
* 2325Kartik K. Agaram2015-10-301-2/+1
|
* 2324 - static dispatch works with arcane headers!Kartik K. Agaram2015-10-291-8/+7
|
* 2323 - static dispatch!Kartik K. Agaram2015-10-293-1/+186
|
* 2322 - deduce types from recipe headerKartik K. Agaram2015-10-291-3/+47
|
* 2321 - more preparations for static dispatchKartik K. Agaram2015-10-2912-65/+75
| | | | | Deduce operation id from name during transform rather than load, so that earlier transforms have a chance to modify the name.
* 2320Kartik K. Agaram2015-10-291-51/+51
|
* 2319Kartik K. Agaram2015-10-291-2/+3
|
* 2318Kartik K. Agaram2015-10-291-1/+1
| | | | Forgot to run against valgrind.
* 2317Kartik K. Agaram2015-10-292-0/+0
|
* 2316 - preparing for static dispatchKartik K. Agaram2015-10-294-16/+28
|
* 2315Kartik K. Agaram2015-10-291-2/+2
|
* 2314 - final tweaks to traceKartik K. Agaram2015-10-293-2/+4
| | | | | | | | I checked these commands: $ mu x.mu $ grep "===" .traces/interactive $ grep "===\|---" .traces/interactive
* 2313Kartik K. Agaram2015-10-2912-35/+32
|
* 2312Kartik K. Agaram2015-10-294-5/+6
|
* 2311Kartik K. Agaram2015-10-2911-80/+85
|
* 2310 - add some more tracingKartik K. Agaram2015-10-293-4/+14
| | | | | | | | | | | 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.
* 2309Kartik K. Agaram2015-10-2821-892/+892
|
* 2308 - auto-reply on fall-throughKartik K. Agaram2015-10-281-0/+30
|
* 2307Kartik K. Agaram2015-10-281-0/+5
|
* 2306 - recipe headersKartik K. Agaram2015-10-2810-16/+132
| | | | | | | | | | 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!)