Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | 1595 | Kartik K. Agaram | 2015-06-18 | 1 | -1/+1 |
| | |||||
* | 1594 - removing from start/end of duplex list | Kartik K. Agaram | 2015-06-18 | 1 | -4/+67 |
| | | | | | | | | | | This uncovers an issue with this interface to duplex lists: the caller needs to check the result and invalidate any other pointers if it's null (i.e. the list is now empty) We *could* try to encapsulate the list in a header to help the caller manage header pointers. But heck, let's see if writing tests helps call-sites stay on the straight and narrow. | ||||
* | 1593 | Kartik K. Agaram | 2015-06-18 | 2 | -1/+77 |
| | |||||
* | 1592 | Kartik K. Agaram | 2015-06-18 | 1 | -0/+36 |
| | |||||
* | 1591 | Kartik K. Agaram | 2015-06-18 | 2 | -3/+60 |
| | |||||
* | 1590 - inserting into doubly linked list | Kartik K. Agaram | 2015-06-18 | 1 | -0/+62 |
| | |||||
* | 1589 - doubly linked list | Kartik K. Agaram | 2015-06-18 | 1 | -0/+74 |
| | |||||
* | 1588 - undo 1587 | Kartik K. Agaram | 2015-06-17 | 1 | -22/+1 |
| | |||||
* | 1587 - experimental rendering of recipe names | Kartik K. Agaram | 2015-06-17 | 1 | -1/+22 |
| | | | | | But this is getting too complex too fast. Let's get a simple editor working first without color. | ||||
* | 1586 | Kartik K. Agaram | 2015-06-17 | 2 | -2/+2 |
| | |||||
* | 1585 | Kartik K. Agaram | 2015-06-17 | 14 | -29/+29 |
| | |||||
* | 1584 | Kartik K. Agaram | 2015-06-17 | 1 | -1/+1 |
| | |||||
* | 1582 | Kartik K. Agaram | 2015-06-17 | 2 | -0/+46 |
| | |||||
* | 1581 | Kartik K. Agaram | 2015-06-17 | 1 | -1/+1 |
| | |||||
* | 1580 | Kartik K. Agaram | 2015-06-16 | 2 | -9/+12 |
| | |||||
* | 1579 | Kartik K. Agaram | 2015-06-16 | 1 | -0/+11 |
| | |||||
* | 1578 - editor inside 2-column layout | Kartik K. Agaram | 2015-06-16 | 1 | -17/+67 |
| | |||||
* | 1577 - vocabulary for drawing borders | Kartik K. Agaram | 2015-06-16 | 1 | -24/+65 |
| | |||||
* | 1576 | Kartik K. Agaram | 2015-06-16 | 1 | -0/+50 |
| | |||||
* | 1575 | Kartik K. Agaram | 2015-06-16 | 1 | -0/+8 |
| | |||||
* | 1573 | Kartik K. Agaram | 2015-06-16 | 5 | -3/+51 |
| | |||||
* | 1572 | Kartik K. Agaram | 2015-06-16 | 2 | -4/+50 |
| | |||||
* | 1571 | Kartik K. Agaram | 2015-06-16 | 1 | -2/+87 |
| | |||||
* | 1570 | Kartik K. Agaram | 2015-06-16 | 1 | -1/+31 |
| | |||||
* | 1569 | Kartik K. Agaram | 2015-06-16 | 2 | -3/+28 |
| | |||||
* | 1568 - starting on editor widget in ernest | Kartik K. Agaram | 2015-06-16 | 1 | -123/+15 |
| | |||||
* | 1566 - fake mouse clicks in scenarios | Kartik K. Agaram | 2015-06-15 | 5 | -1/+197 |
| | |||||
* | 1565 | Kartik K. Agaram | 2015-06-14 | 2 | -32/+5 |
| | |||||
* | 1564 - a better way to support string literals | Kartik K. Agaram | 2015-06-14 | 4 | -7/+78 |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. | ||||
* | 1563 | Kartik K. Agaram | 2015-06-14 | 1 | -1/+1 |
| | |||||
* | 1562 | Kartik K. Agaram | 2015-06-14 | 1 | -0/+5 |
| | |||||
* | 1561 | Kartik K. Agaram | 2015-06-14 | 1 | -0/+7 |
| | |||||
* | 1560 | Kartik K. Agaram | 2015-06-13 | 2 | -17/+20 |
| | |||||
* | 1559 | Kartik K. Agaram | 2015-06-13 | 1 | -0/+2 |
| | |||||
* | 1558 | Kartik K. Agaram | 2015-06-13 | 1 | -0/+10 |
| | | | | Make it possible to check multi-line string literals in the trace. | ||||
* | 1557 | Kartik K. Agaram | 2015-06-13 | 2 | -5/+13 |
| | | | | More concise traces for literal strings. | ||||
* | 1556 | Kartik K. Agaram | 2015-06-12 | 65 | -642/+1203 |
| | |||||
* | 1555 - mu.vim: distinguish control-flow from constants | Kartik K. Agaram | 2015-06-12 | 2 | -7/+8 |
| | | | | We also do this in regular C++ now. | ||||
* | 1554 | Kartik K. Agaram | 2015-06-11 | 1 | -1/+2 |
| | |||||
* | 1553 | Kartik K. Agaram | 2015-06-11 | 3 | -0/+0 |
| | |||||
* | 1552 - mouse support | Kartik K. Agaram | 2015-06-11 | 2 | -0/+44 |
| | |||||
* | 1551 - initial sketch of layout | Kartik K. Agaram | 2015-06-11 | 1 | -1/+53 |
| | | | | | | | | | | | | | | | Two columns: edit code on left and run code on right. In both columns, the action is at the top of the screen, and stuff gradually flows downward unless pulled back up. Stuff you run on the right side will eventually become reproducible test cases that runs constantly on every change. We also have a tentative signature for the 'edit' routine: it'll take an input string and return an output string when it finishes. More columns expand to the right. Number of columns shown will remain fixed at any time depending on screen width. But for now we support exactly two columns. | ||||
* | 1550 | Kartik K. Agaram | 2015-06-10 | 1 | -0/+7 |
| | |||||
* | 1549 | Kartik K. Agaram | 2015-06-09 | 67 | -191/+794 |
| | |||||
* | 1548 | Kartik K. Agaram | 2015-06-09 | 1 | -2/+2 |
| | |||||
* | 1547 | Kartik K. Agaram | 2015-06-09 | 1 | -0/+1 |
| | |||||
* | 1546 - show crucial code samples in color | Kartik K. Agaram | 2015-06-08 | 1 | -23/+36 |
| | |||||
* | 1545 - sketching out a simple editor widget | Kartik K. Agaram | 2015-06-08 | 3 | -0/+131 |
| | |||||
* | 1544 - arrow keys in trace browser | Kartik K. Agaram | 2015-06-07 | 1 | -4/+4 |
| | |||||
* | 1543 | Kartik K. Agaram | 2015-06-07 | 2 | -3/+3 |
| |