about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* 2579Kartik K. Agaram2016-01-202-0/+9
| | | | Separate core mu tests from those loaded from the commandline.
* 2578Kartik K. Agaram2016-01-202-4/+4
|
* 2577Kartik K. Agaram2016-01-201-49/+50
|
* 2576 - distinguish allocated addresses from othersKartik K. Agaram2016-01-1956-3300/+3364
| | | | | | | | | | | | | | | | This is the one major refinement on the C programming model I'm planning to introduce in mu. Instead of Rust's menagerie of pointer types and static checking, I want to introduce just one new type, and use it to perform ref-counting at runtime. So far all we're doing is updating new's interface. The actual ref-counting implementation is next. One implication: I might sometimes need duplicate implementations for a recipe with allocated vs vanilla addresses of the same type. So far it seems I can get away with just always passing in allocated addresses; the situations when you want to pass an unallocated address to a recipe should be few and far between.
* 2575 - better messages on trace count failuresKartik K. Agaram2016-01-193-3/+13
|
* 2574Kartik K. Agaram2016-01-192-15/+12
|
* 2573 - check product type of 'new'Kartik K. Agaram2016-01-194-10/+38
| | | | | | | | | | | I realize that my current doesn't allow nesting a:b:c linear type syntax inside a dilated property. So you can't currently say: (recipe address:number) Need to fix that at some point. Non-trivial since linear syntax is oblivious to dilated syntax. I should probably make the dilated syntax more fundamental and introduce it at an earlier layer.
* 2572Kartik K. Agaram2016-01-191-1/+1
|
* 2571Kartik K. Agaram2016-01-196-4/+4
| | | | | Reorganize layers in preparation for a better way to manage heap allocations without ever risking use-after-free errors.
* 2570 - recipe variables are now fully type-checkedKartik K. Agaram2016-01-181-0/+31
|
* 2569Kartik K. Agaram2016-01-184-6/+17
|
* 2568Kartik K. Agaram2016-01-181-0/+17
|
* 2567Kartik K. Agaram2016-01-181-2/+7
|
* 2566 - typecheck 'call' on recipe variablesKartik K. Agaram2016-01-181-1/+25
|
* 2565 - typecheck 'call' on literal recipesKartik K. Agaram2016-01-181-0/+48
|
* 2564Kartik K. Agaram2016-01-182-8/+6
|
* 2563 - bring back 'call'Kartik K. Agaram2016-01-182-1/+59
| | | | Still need to type-check it, though.
* 2562Kartik K. Agaram2016-01-1713-49/+47
| | | | | | | | | | | | We want to use the type 'recipe' for recipe *variables*, because it seems nicer to say `recipe number -> number` rather than recipe-ordinal, etc. To support this we'll allow recipe names to be mentioned without any type. This might make a couple of places in this commit more brittle. I'm dropping error messages, causing them to not happen in some situations. Maybe I should just bite the bullet and require an explicit :recipe-literal. We'll see.
* 2561Kartik K. Agaram2016-01-176-32/+33
| | | | | Reorganize layers in preparation for a better, more type-safe implementation of first-class and higher-order recipes.
* 2560Kartik K. Agaram2016-01-131-5/+3
|
* 2559 - stop using 'next-ingredient' explicitlyKartik K. Agaram2016-01-125-30/+19
| | | | | I still need it in some situations because I have no way to set a non-zero default for an optional ingredient. Open question..
* 2558Kartik K. Agaram2016-01-122-2/+8
|
* 2557 - type-check most ingredients ahead of timeKartik K. Agaram2016-01-125-48/+86
|
* 2556Kartik K. Agaram2016-01-121-1/+2
|