about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 2987Kartik K. Agaram2016-05-207-0/+0
|
* 2986 - new example: the 8-queens problemKartik K. Agaram2016-05-202-0/+100
| | | | Just playing around with edit/ and trying to find bugs.
* 2985 - allow multiple pointers within listsKartik K. Agaram2016-05-201-3/+2
| | | | | | | | | | Earlier, this wasn't legal: y:address:list:number <- push 34, x:address:list:number (So that x and y would point to different places in the list.) However, functional code relies on this ability a lot.
* 2984Kartik K. Agaram2016-05-191-0/+272
| | | | Missed a file.
* 2983 - migrate buttons over to sandbox/Kartik K. Agaram2016-05-1914-384/+366
|
* 2982Kartik K. Agaram2016-05-191-6/+6
|
* 2981 - sandbox buttons implemented in edit/Kartik K. Agaram2016-05-195-123/+379
|
* 2980Kartik K. Agaram2016-05-191-0/+3
|
* 2979Kartik K. Agaram2016-05-195-0/+0
|
* 2978 - support new 'edit' button in edit/Kartik K. Agaram2016-05-193-26/+101
|
* 2977 - draw new sandbox menu in edit/Kartik K. Agaram2016-05-197-376/+401
| | | | | | | | | | | | | Doesn't work as advertised yet. This is just the render piece, and fixing all the tests. I've been careful to try to break tests for edit once I implement the button. Delete I can't ensure will break afterwards. Remember to test clicking on multiple places on the menu. Managing the screens is starting to grow onerous; maybe we need something called normalize which clears some things. But the sandbox menu can be on arbitrary lines..
* 2976Kartik K. Agaram2016-05-191-4/+18
|
* 2975Kartik K. Agaram2016-05-198-19/+21
| | | | Clean up this helper before we start redoing sandbox menubars.
* 2974Kartik K. Agaram2016-05-182-23/+24
| | | | Fix CI failure.
* 2973 - reclaim refcounts for local scopes againKartik K. Agaram2016-05-185-46/+167
| | | | | | More thorough redo of commit 2767 (Mar 12), which was undone in commit 2810 (Mar 24). It's been a long slog. Next step: write a bunch of mu code in the edit/ app in search of bugs.
* 2972 - abandon recursive containersKartik K. Agaram2016-05-173-15/+129
|
* 2971Kartik K. Agaram2016-05-1715-32/+25
| | | | | | Long-overdue reorganization to support general 'dilated' reagents up front. This also allows me to move tests that are really about unrelated layers out of layers dealing with parsing.
* 2970Kartik K. Agaram2016-05-171-4/+4
|
* 2969Kartik K. Agaram2016-05-171-1/+1
|
* 2968Kartik K. Agaram2016-05-174-17/+42
| | | | | | | | | | | | | | | | | | | | | | | More reorganization in preparation for implementing recursive abandon(). Refcounts are getting incredibly hairy. I need to juggle containers containing other containers, and containers *pointing* to other containers. For a while I considered getting rid of address_element_info entirely and just going by types for every single update_refcount. But that's definitely more work, and it's unclear that things will be cleaner/shorter/simpler. I haven't measured the speedup, but it seems worth optimizing every pointer copy to make sure we aren't manipulating types at runtime. The key insight now is a) to continue to compute information about nested containers at load time, because that's the common case when updating refcounts, but b) to compute information about *pointed* values at run-time, because that's the uncommon case. As a result, we're going to cheat in the interpreter and use type information at runtime just for abandon(), just because the corresponding task when we get to a compiler will be radically different. It will still be tractable, though.
* 2967Kartik K. Agaram2016-05-172-19/+19
|
* 2966Kartik K. Agaram2016-05-173-8/+10
|
* 2965 - update refcounts when copying containersKartik K. Agaram2016-05-155-65/+149
| | | | | | This is hopefully quite thorough. I handle nested containers, as well as exclusive containers that might contain addresses only when the tag has a specific value.
* 2964Kartik K. Agaram2016-05-151-2/+1
|
* 2963Kartik K. Agaram2016-05-151-38/+42
| | | | | | To support exclusive containers a recursive answer will be easier to reuse than the current iterative one. First step: figure out the precise boundary and interface of the recursive function.
* 2962Kartik K. Agaram2016-05-151-0/+3
|
* 2961Kartik K. Agaram2016-05-153-5/+5
|
* 2960Kartik K. Agaram2016-05-151-7/+7
| | | | First genuine Travis CI failure fixed! May there be many more.
* 2959Kartik K. Agaram2016-05-142-8/+81
|
* 2958Kartik K. Agaram2016-05-141-1/+30
|
* 2957Kartik K. Agaram2016-05-141-8/+57
|
* 2956Kartik K. Agaram2016-05-142-4/+8
|
* 2955 - back to more refcount housekeepingKartik K. Agaram2016-05-127-35/+133
| | | | | Update refcounts of address elements when copying containers. Still lots to do; see todo list at end of 036refcount.cc.
* 2954 - bugfix: $systemKartik K. Agaram2016-05-116-19/+19
| | | | The actual fix is in the layer rewriting literal strings.
* 2953 - use pgup/pgdn to scroll through sandboxesKartik K. Agaram2016-05-119-1628/+127
| | | | | | In the process I've also simplified the sandbox/ app. Since it's impossible for sandbox editors to span multiple pages, we can drop all scroll support altogether.
* 2952 - multi-ary min/maxKartik K. Agaram2016-05-112-22/+78
|
* 2951Kartik K. Agaram2016-05-091-3/+0
|
* 2950 - more Travis load-balancingKartik K. Agaram2016-05-091-4/+3
|
* 2949 - disable Valgrind on app layer testsKartik K. Agaram2016-05-091-44/+33
| | | | | | | | | | | | | I kept suspecting Valgrind and kept finding that Valgrind wasn't actually slowing down Travis CI, but I'd been running it like this: valgrind ./mu test edit Which wasn't actually running the underlying ./mu_bin binary atop Valgrind. Ok, so Mu is just super slow running any non-trivial apps atop Valgrind. That's ok, we've rarely needed an app to flush out memory leaks in Mu.
* 2948Kartik K. Agaram2016-05-081-0/+1
|
* 2947Kartik K. Agaram2016-05-081-2/+3
|
* 2946Kartik K. Agaram2016-05-084-36/+32
| | | | | | | | | | | | | Reorganize build system to minimize duplication while handling 3 scenarios: 1. Locally running tests with `mu test` 2. Locally running tests until some layer with `build_and_test_until` 3. Running on Linux with `test_layers` 4. Running on Travis CI with multiple sharded calls to `test_layers` One thing we drop at this point is support for OSX in test_layers. We don't need it now that we have Travis CI working.
* 2945Kartik K. Agaram2016-05-082-10/+54
| | | | More tweaking; edit/ still taking too long to test on Travis CI.
* 2944Kartik K. Agaram2016-05-082-5/+17
| | | | | | | | | 2943 almost worked; just a couple of tweaks: a) Divide up the work a little more finely since we still timed out on some jobs. b) Use clang and valgrind when running apps as well.
* 2943Kartik K. Agaram2016-05-081-4/+8
| | | | | I misunderstood what constitutes a job in Travis CI. Let's try this again..
* 2942 - switch scripts to bashKartik K. Agaram2016-05-083-8/+8
| | | | | I'm already using grep and perl, bash is no worse, and it's *much* nicer to work in than plain Bourne sh.
* 2941 - split Travis CI into multiple jobsKartik K. Agaram2016-05-083-18/+36
| | | | It easily exceeded the 50-minute timeout.
* 2940Kartik K. Agaram2016-05-081-0/+2
|
* 2939Kartik K. Agaram2016-05-081-4/+4
|
* 2938 - ok, let's try CIKartik K. Agaram2016-05-081-0/+21
| | | | https://travis-ci.org/akkartik/mu
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-14 11:52:44 +0000