about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 2392 - undo 2391Kartik K. Agaram2015-11-079-133/+61
| | | | Yup, type ingredients were taking size 1 by default.
* 2391Kartik K. Agaram2015-11-079-59/+133
| | | | | | | | | | | | | 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.
* 2390 - undo 2389Kartik K. Agaram2015-11-073-9/+3
| | | | Ooh, I think I see a solution.
* 2389Kartik K. Agaram2015-11-073-3/+9
| | | | | | | | 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-074-41/+62
|
* 2387 - edit/ passing except that final undo layerKartik K. Agaram2015-11-071-0/+2
|
* 2386 - core tests passing againKartik K. Agaram2015-11-072-2/+3
| | | | Layer 1 of edit/ is introducing spurious types, though.
* 2385 - tests passing until layer 58Kartik K. Agaram2015-11-071-2/+7
|
* 2384 - tests pass until layer 54Kartik K. Agaram2015-11-072-1/+4
|
* 2383 - new concern: idempotence of transformsKartik K. Agaram2015-11-0612-14/+14
| | | | | I'd not paid any attention to it so far, but I need to do so from now on.
* 2382Kartik K. Agaram2015-11-0613-13/+68
| | | | Starting to leave commented out prints again out of desperation.
* 2381Kartik K. Agaram2015-11-062-4/+14
|
* 2380 - done loading mu codeKartik K. Agaram2015-11-066-23/+27
| | | | | | | | New assertions still failing during tests. This whole implementation of generic recipes is like an extended spike. I don't have nearly enough tests. Ideally I'd have confidence in generics once layer 59 passed its tests.
* 2379 - further improvements to map operationsKartik K. Agaram2015-11-0619-51/+56
| | | | | | | 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-066-12/+12
| | | | | | 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-0645-575/+593
| | | | | | | | | | | | | | | | 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.
* 2376Kartik K. Agaram2015-11-051-7/+7
|
* 2375 - layer 9 doneKartik K. Agaram2015-11-051-6/+5
|
* 2374 - now edit works until layer 8Kartik K. Agaram2015-11-055-83/+73
|
* 2373 - bad bug: instruction was losing /lookupKartik K. Agaram2015-11-053-2/+18
|
* 2372Kartik K. Agaram2015-11-051-0/+4
|
* 2371 - layer 5 of editKartik K. Agaram2015-11-054-68/+45
|
* 2370 - layers 1-4 of edit are backKartik K. Agaram2015-11-055-357/+325
| | | | | | | | | | | | 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>.
* 2369 - layer 1 of edit is backKartik K. Agaram2015-11-052-34/+18
|
* 2368 - start getting edit working againKartik K. Agaram2015-11-052-23/+31
| | | | | Still seeing repeated null refinements. Maybe my approach to fixing those errors is fundamentally broken.
* 2367Kartik K. Agaram2015-11-051-1/+1
|
* 2366 - disallow static dispatch inside header-less recipesKartik K. Agaram2015-11-051-0/+1
| | | | | Not only can such recipes not have variants, their bodies too will be oblivious to multiple variants or generics.
* 2365Kartik K. Agaram2015-11-051-10/+10
|
* 2364Kartik K. Agaram2015-11-051-0/+10
|
* 2363 - duplex-list is now generic.Kartik K. Agaram2015-11-052-252/+252
| | | | It wasn't a phase-ordering issue after all..
* 2362Kartik K. Agaram2015-11-042-1/+2
| | | | | | Now we try to be smarter about checking for presence in the Type array. Still can't get generic duplex-list to work.
* 2361Kartik K. Agaram2015-11-041-1/+2
|
* 2360Kartik K. Agaram2015-11-0411-15/+60
| | | | | | | | | 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.
* 2359Kartik K. Agaram2015-11-041-1/+1
|
* 2358 - starting to tackle the phase ordering problemKartik K. Agaram2015-11-0413-30/+32
| | | | | | | 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.
* 2357Kartik K. Agaram2015-11-041-1/+1
|
* 2356Kartik K. Agaram2015-11-041-8/+12
| | | | | I keep finding null property pointers and am fucking sick of wondering if it's because of this horseshit.
* 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.