about summary refs log tree commit diff stats
path: root/013literal_string.cc
Commit message (Collapse)AuthorAgeFilesLines
* 1913 - save expected response for each sandboxKartik K. Agaram2015-08-011-2/+5
|
* 1876Kartik K. Agaram2015-07-281-13/+12
|
* 1844 - explicitly end each trace lineKartik K. Agaram2015-07-251-2/+2
| | | | | | | | | More verbose, but it saves trouble when debugging; there's never something you thought should be traced but just never came out the other end. Also got rid of fatal errors entirely. Everything's a warning now, and code after a warning isn't guaranteed to run.
* 1702 - experiment: start using 'ordinal' in namesKartik K. Agaram2015-07-041-1/+1
| | | | | | | It comes up pretty early in the codebase, but hopefully won't come up in the mu level until we get to higher-order recipes. Potentially intimidating name, but such prime real estate with no confusing overloadings in other projects!
* 1598Kartik K. Agaram2015-06-191-3/+20
| | | | | Some tests weren't actually running for the past 5 days. Performed 5 why's.
* 1565Kartik K. Agaram2015-06-141-1/+1
|
* 1564 - a better way to support string literalsKartik K. Agaram2015-06-141-5/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our new heuristic is: all string literals are the same. If they contain newline before non-whitespace, we scan for comments assuming there might be code inside: foofoofoo [ ... # ']' inside comment ignored ] If they contain non-whitespace first, then we ignore comments assuming it's just a regular string: foofoofoo [abc#def] # valid string literal The big hole in this approach: foofoofoo [ # what about comments here containing ']'? ... # abc ] Currently this reads as a 'code comment' and terminates before the newline or '?' and will probably trigger errors down the line. Temporary workaround: don't start code strings with a comment on the same line as the '['. Eventually we'll tighten up the logic. We're still not using the new heuristic in scenarios, but that's up next.
* 1563Kartik K. Agaram2015-06-141-1/+1
|
* 1562Kartik K. Agaram2015-06-141-0/+5
|
* 1561Kartik K. Agaram2015-06-141-0/+7
|
* 1560Kartik K. Agaram2015-06-131-0/+20
|
* 1557Kartik K. Agaram2015-06-131-5/+5
| | | | More concise traces for literal strings.
* 1515 - complain on unbalanced bracketsKartik K. Agaram2015-05-301-0/+4
|
* 1502Kartik K. Agaram2015-05-281-5/+5
|
* 1497 - 2 boneheaded bugs in parsing scenariosKartik K. Agaram2015-05-281-1/+11
|
* 1414 - traces now robust to new recipes/typesKartik K. Agaram2015-05-211-5/+5
|
* 1391 - avoid unsigned integersKartik K. Agaram2015-05-171-1/+1
|
* 1299 - stop using [] in any vectorKartik K. Agaram2015-05-071-3/+3
| | | | | | | | | Useful check: $ grep "[^ '\"]\[[^\"]" *.cc \ |perl -pwe 's/\Wargv\[|\WTests\[|\Wframe\[|\WMemory\[|\WName\[|\WSurrounding_space\[|\WRecipe\[|\WType\[|\WRecipe_number\[|\WType_number\[|\WBefore_fragments\[|\WAfter_fragments\[//g' \ |perl -pwe 's/\Wargv\[|\WTests\[|\Wframe\[|\WMemory\[|\WName\[|\WSurrounding_space\[|\WRecipe\[|\WType\[|\WRecipe_number\[|\WType_number\[|\WBefore_fragments\[|\WAfter_fragments\[//g' \ |grep '[^ ]\['
* 1276 - make C++ version the defaultKartik K. Agaram2015-05-051-0/+78
I've tried to update the Readme, but there are at least a couple of issues.