about summary refs log tree commit diff stats
path: root/030container.cc
Commit message (Collapse)AuthorAgeFilesLines
* 2475 - allow addresses to be converted to numbersKartik K. Agaram2015-11-271-7/+10
| | | | It's just the other direction we want to avoid.
* 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
* 2465 - improve an error messageKartik K. Agaram2015-11-201-4/+4
| | | | Thanks Caleb Couch.
* 2457Kartik K. Agaram2015-11-171-3/+4
|
* 2454Kartik K. Agaram2015-11-171-2/+2
| | | | | | 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().
* 2450 - another pesky bugKartik K. Agaram2015-11-151-0/+11
|
* 2406Kartik K. Agaram2015-11-081-6/+2
| | | | | One new issue: the traces for all tests are perturbed by the .mu files we choose to load.
* 2403 - experiment: documenting non-assertionsKartik K. Agaram2015-11-081-1/+1
| | | | | | | Is that like a Maybe type in a type system? No it's more, it captures the wistful longing of several hours spent trying to make an assertion true. Not even by moving my phases relating to the types around could I make this assertion true.
* 2402Kartik K. Agaram2015-11-081-2/+2
|
* 2400 - eliminate last few warningsKartik K. Agaram2015-11-081-2/+2
|
* 2399 - consistent debug_string vocabularyKartik K. Agaram2015-11-081-3/+3
|
* 2383 - new concern: idempotence of transformsKartik K. Agaram2015-11-061-1/+1
| | | | | I'd not paid any attention to it so far, but I need to do so from now on.
* 2382Kartik K. Agaram2015-11-061-9/+44
| | | | Starting to leave commented out prints again out of desperation.
* 2381Kartik K. Agaram2015-11-061-4/+12
|
* 2380 - done loading mu codeKartik K. Agaram2015-11-061-4/+4
| | | | | | | | 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-061-4/+4
| | | | | | | 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-3/+3
| | | | | | 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-55/+55
| | | | | | | | | | | | | | | | 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.
* 2373 - bad bug: instruction was losing /lookupKartik K. Agaram2015-11-051-2/+2
|
* 2362Kartik K. Agaram2015-11-041-1/+1
| | | | | | Now we try to be smarter about checking for presence in the Type array. Still can't get generic duplex-list to work.
* 2360Kartik K. Agaram2015-11-041-0/+2
| | | | | | | | | 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-3/+3
| | | | | | | 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.
* 2341 - fill in gaps in generic containersKartik K. Agaram2015-11-011-9/+17
|
* 2340Kartik K. Agaram2015-11-011-7/+5
|
* 2329 - hacky start to generic containersKartik K. Agaram2015-10-301-0/+2
|
* 2327Kartik K. Agaram2015-10-301-4/+1
|
* 2326Kartik K. Agaram2015-10-301-8/+8
|
* 2313Kartik K. Agaram2015-10-291-3/+3
|
* 2311Kartik K. Agaram2015-10-291-8/+8
|
* 2293Kartik K. Agaram2015-10-271-1/+1
|
* 2284Kartik K. Agaram2015-10-261-6/+6
|
* 2281Kartik K. Agaram2015-10-261-25/+0
|
* 2280Kartik K. Agaram2015-10-261-3/+3
|
* 2277 - reagents now have a tree of typesKartik K. Agaram2015-10-251-57/+79
|
* 2266 - drop experiment with genericsKartik K. Agaram2015-10-071-124/+0
|
* 2258 - separate warnings from errorsKartik K. Agaram2015-10-061-43/+43
| | | | | | | 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.
* 2251Kartik K. Agaram2015-10-051-1/+17
| | | | | | Unbelievable that this hitherto-unanticipated test passed so easily. Even though I'm simply bolting on special cases in an ad hoc manner, this isn't too shabby.
* 2250Kartik K. Agaram2015-10-051-3/+48
|
* 2249 - start of type ingredients or genericsKartik K. Agaram2015-10-051-10/+79
| | | | | *Extremely* ugly. I need to use better variable names around new waypoints.
* 2248Kartik K. Agaram2015-10-051-9/+6
|
* 2243Kartik K. Agaram2015-10-051-1/+1
|
* 2242Kartik K. Agaram2015-10-051-0/+2
|
* 2241 - back to type-checking get-addressKartik K. Agaram2015-10-051-1/+23
| | | | | Now duplex-list is fully non-generic and only works with characters. But we'll fix that in a bit..
* 2234 - check type of get's productKartik K. Agaram2015-10-021-1/+32
| | | | Already I'm finding type errors in the programming environment.
* 2233 - basic checks for non-primitive recipesKartik K. Agaram2015-10-011-1/+6
| | | | This came last because we had to ensure all primitives are covered.
* 2227 - offset-checking for containersKartik K. Agaram2015-10-011-32/+59
|
* 2226 - standardize warning formatKartik K. Agaram2015-10-011-6/+6
| | | | | | | | Always show recipe name where error occurred. But don't show internal 'interactive' name for sandboxes, that's just confusing. What started out as warnings are now ossifying into errors that halt all execution. Is this how things went with C and Unix as well?
* 2218 - check types in instructions much earlierKartik K. Agaram2015-09-301-1/+1
| | | | | | | | | Front-loads it a bit more than I'd like, but the payoff is that other recipes will now be able to describe the type checks right next to their operation. I'm also introducing a new use of /raw with literals to indicate unsafe typecasts.
* 2154 - check types only after loading all layersKartik K. Agaram2015-09-051-1/+1
| | | | | Follow-up to 2147, which switched transform_all to only run once, after loading all layers.
* 2137Kartik K. Agaram2015-09-031-1/+0
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-17 11:42:20 +0000