about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 2629 - starting work on hash tablesKartik K. Agaram2016-02-061-0/+28
|
* 2628Kartik K. Agaram2016-02-051-0/+1
| | | | | Ran into a crash here while loading Caleb's deck-of-war program. Not bothering debugging it..
* 2627 - bitwise operatorsKartik K. Agaram2016-02-041-0/+283
|
* 2626Kartik K. Agaram2016-02-031-0/+80
|
* 2625Kartik K. Agaram2016-02-0224-158/+457
|
* 2624Kartik K. Agaram2016-02-014-30/+46
| | | | Reorganize further to make edit/008-sandbox-test more self-contained.
* 2623 - bugfix: editing sandboxesKartik K. Agaram2016-02-017-12/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you restore 2 sandboxes, the first render was setting response-starting-row-on-screen on both, without ever rendering a response. If the lower sandbox contained a print and rendered the screen instead of the response, the original response-starting-row-on-screen was never reset. If the process of running the sandboxes caused the lower sandbox's title bar to move below the now-stale response-starting-row-on-screen[1], editing the lower sandbox no longer works. [1] (Either because the upper sandbox prints to screen as well (causing the first F4 to move the lower sandbox down by several lines), or because a fresh sandbox is created with several lines before the first F4 is hit.) Current solution: never set response-starting-row-on-screen during reload (or otherwise when there's no response). This is hard to test right now because 'restore' is not a tested interface, and I can't come up with another situation where the response-starting-row-on-screen goes stale. So I'm now trying to keep all changes to response-starting-row-on-screen close together. Another idea is to add a check that the click row lies below the response-starting row *and* above the start of the next sandbox. (But what if there's no next sandbox?) (This bug is really a regression, introduced last Sep in 2163.)
* 2622 - bugfix: left-arrowKartik K. Agaram2016-01-312-6/+156
| | | | Moving back to wrapped line was overflowing the right margin.
* 2621 - bugfix: empty shape-shifting recipesKartik K. Agaram2016-01-301-6/+17
| | | | | My transform pipeline ignores empty recipes, but when I specialized shape-shifting ones I forgot that check.
* 2620Kartik K. Agaram2016-01-304-56/+56
| | | | | I was finding it hard to wrap around the directionality of calls with 'lhs' and 'rhs'. Seems to work better with 'to' and 'from'. Let's see.
* 2619 - actually allow coercing booleans to numbersKartik K. Agaram2016-01-302-4/+22
| | | | | This uncovered a bug where I've been forgetting the directionality of arguments to types_coercible().
* 2618 - support stashing booleansKartik K. Agaram2016-01-301-0/+8
|
* 2617 - better error messagesKartik K. Agaram2016-01-303-2/+50
| | | | | | | | | | | | | | | | | | When we stash a value, mu does several levels of work for us: a) First it inserts instructions above the stash to convert the value to text using to-text-line. b) to-text-line calls to-text. Both are shape-shifting, so multiple levels of specialization happen. To give a good error message, we track the 'stack' of current specializations at the time of the error, and also check if the offending instruction at the top-most level looks like it was inserted while rewriting stash instructions. Manual example (since booleans can't be stashed at the moment): x:boolean <- copy 1/true stash x
* 2616Kartik K. Agaram2016-01-301-0/+1
| | | | Drop yet another source of perturbance in traces.
* 2615Kartik K. Agaram2016-01-301-2/+2
|
* 2614Kartik K. Agaram2016-01-294-9/+9
|
* 2613 - better error message when forgetting 'shared'Kartik K. Agaram2016-01-281-7/+21
|
* 2612 - sandbox/ tests always show recipe errorsKartik K. Agaram2016-01-282-18/+39
| | | | | I spent the longest time trying to understand what bug 2268 fixed. But it's being tested now.
* 2611Kartik K. Agaram2016-01-271-1/+1
|
* 2610 - warn when recipes don't use default-spaceKartik K. Agaram2016-01-277-11/+74
| | | | Somehow this never transferred over from the Arc version until now.
* 2609 - reuse test-recipe variables in sandbox/ testsKartik K. Agaram2016-01-274-4/+75
| | | | | | | | I'd feared that the refcount errors in the previous commit meant there was a bug in my ref-counting, so I temporarily used new variables rather than reusing existing ones. But it turns out the one remaining place memory corruption can happen is when recipes don't use default-scope and so end up sharing memory. Don't I have a warning for this?
* 2608 - fix-up tests in sandbox/ appKartik K. Agaram2016-01-279-94/+690
| | | | | | | | | | When I first forked it from the edit/ app, I wasn't sure how to deal with changing the recipe side when the only way the program accesses it is with the untestable 'restore' hack. Now we introduce a little hook into event-loop and pass in any updated recipe side directly. In the process I've cleaned up several minor stylistic inconsistencies between edit/ and sandbox/ apps.
* 2607Kartik K. Agaram2016-01-271-1/+0
|
* 2606 - fix crashKartik K. Agaram2016-01-271-1/+1
| | | | Thanks Caleb Couch.
* 2605Kartik K. Agaram2016-01-2668-2830/+4239
|
* 2604 - clearing line was sometimes hiding cursorKartik K. Agaram2016-01-251-1/+1
| | | | Caused by 2591.
* 2603 - bugfix: defining main with commandline argsKartik K. Agaram2016-01-253-13/+12
| | | | Pretty hacky fix: we simply suppress static dispatch for main.
* 2602Kartik K. Agaram2016-01-241-1/+1
|
* 2601 - fix crashKartik K. Agaram2016-01-241-2/+4
|
* 2600 - teach 'print' about addressesKartik K. Agaram2016-01-231-0/+20
| | | | Unfortunate that our type system requires this to be explicit..
* 2599 - abandon should clear its argumentKartik K. Agaram2016-01-231-11/+27
| | | | | Is this a violation of our requirement to always treat ingredients as immutable? We shouldn't be using it much anyway..
* 2598 - bugfix: scrolling after editKartik K. Agaram2016-01-231-0/+72
|
* 2597Kartik K. Agaram2016-01-231-0/+3
| | | | Finish 2595.
* 2596 - experiment: no unique addresses in callsKartik K. Agaram2016-01-232-3/+41
| | | | | | | | | | Reading http://www.jonathanturner.org/2016/01/rust-and-blub-paradox.html, I realize there's nothing currently stopping mu programs from taking a unique (non-shared) address into a shared allocation, abandoning the allocation and being left with an invalid address. No fix for this yet, but let's try to minimize its effect by limiting lifetimes of unique addresses. We really should only be using them to write to array or container elements.
* 2595 - bugfix: update state when restoring sandboxesKartik K. Agaram2016-01-231-0/+3
|
* 2594 - bugfixes: managing state when deletingKartik K. Agaram2016-01-236-187/+615
| | | | This required completely redesigning scrolling.
* 2593 - bugfix: editing a sandbox resets scrollKartik K. Agaram2016-01-222-0/+108
|
* 2592 - bugfix: sandbox title bar managementKartik K. Agaram2016-01-222-2/+169
|
* 2591Kartik K. Agaram2016-01-222-2/+14
|
* 2590 - support scrolling through sandboxesKartik K. Agaram2016-01-2214-26/+741
|
* 2589 - tweak color for sandbox labelsKartik K. Agaram2016-01-222-4/+4
| | | | | | | | | | | | | | | | | | | | I'm now thinking about how to support scrolling on the sandbox side. Caleb's idea is to use down-arrow inside the sandbox editor, and then "scroll off" the editor to the top of each successive sandbox. I think I'll reserve the white background as the cursor color in that situation. I wonder if I should just undo all the support for sandbox labels since yesterday. Labels are perhaps superfluous once I support scrolling and reorder sandboxes to always throw ones with errors up top. But then you can end up scrolling through lots of tests without any sense of how far down you are. So the other approach is to keep labels and try to keep them stable, not reorder them. Looking further ahead I'm going to need a way to jump to a specific sandbox. Maybe instead of reordering sandboxes I should just automatically render from the first sandbox with error. Maybe show the number of failed sandboxes in the status instead of the index of the first failure.
* 2588 - bugfix: show *first* sandbox with errorKartik K. Agaram2016-01-222-1/+57
|
* 2587 - bugfix: show-screen on warningsKartik K. Agaram2016-01-222-2/+0
| | | | See `cannot_write_tests_for`.
* 2586 - show first sandbox with error in statusKartik K. Agaram2016-01-229-30/+137
|
* 2585 - label sandboxes with a numberKartik K. Agaram2016-01-2212-50/+80
| | | | | | | | | It also seems useful that the number maps to the name of the file the sandbox is saved in. However this mapping is currently a happy accident and not actually tested. I'm starting to switch gears and help make the editor useable with many many sandboxes. This is just the first step of several.
* 2584Kartik K. Agaram2016-01-211-1/+1
|
* 2583 - start maintaining refcountsKartik K. Agaram2016-01-212-3/+68
| | | | | | | | | | | | Also start auto-abandoning addresses when their refcount returns to 0. I'm mixing this auto-abandon support with my earlier/hackier support for automatically abandoning default-space created by 'local-scope'. We need to flesh out the story for automatically reclaiming memory using C++-style destructors. But that's a value-add. Memory corruption is far more important to avoid than memory *leaks*.
* 2582Kartik K. Agaram2016-01-201-2/+2
|
* 2581 - make space for the refcount in address:sharedKartik K. Agaram2016-01-207-53/+97
| | | | | | | | | | | We don't yet actually maintain the refcount. That's next. Hardest part of this was debugging the assume-console scenarios in layer 85. That took some detailed manual diffing of traces (because the output of diff was no good). New tracing added in this commit add 8% to .traces LoC. Commented out trace() calls (used during debugging) make that 45%.
* 2580 - check product type of 'maybe-convert'Kartik K. Agaram2016-01-204-28/+70
| | | | I had to undo some over-zealous changes in 2576.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-19 03:16:19 +0000