about summary refs log tree commit diff stats
path: root/072scheduler.cc
Commit message (Collapse)AuthorAgeFilesLines
* 3877Kartik K. Agaram2017-05-261-4/+4
|
* 3819Kartik K. Agaram2017-04-131-1/+1
| | | | | | | Yet another attempt at trying to clean up commit 3216. I think this solution might finally let me stop agonizing over the problem. State variables for distinguishing call-sites are a reasonable mechanism, orthogonal to waypoints and the hook functions to hold them.
* 3803Kartik K. Agaram2017-03-201-1/+1
|
* 3656Kartik K. Agaram2016-11-101-3/+3
| | | | | | | | | | | | | | Periodic cleanup to replace 'reply' with 'return' everywhere in the repo. I use 'reply' for students to help reinforce the metaphor of function calls as being like messages through a pipe. But that causes 'reply' to get into my muscle memory when writing Mu code for myself, and I worry that that makes Mu seem unnecessarily alien to anybody reading on Github. Perhaps I should just give it up? I'll try using 'return' with my next student.
* 3629 - refcount commandline argsKartik K. Agaram2016-11-061-0/+2
|
* 3555Kartik K. Agaram2016-10-221-2/+2
|
* 3545Kartik K. Agaram2016-10-221-0/+15
| | | | Type-check ingredients of 'start-running'
* 3530Kartik K. Agaram2016-10-201-6/+2
| | | | Coalesce some duplicate signalling that the current test failed.
* 3529Kartik K. Agaram2016-10-201-0/+17
| | | | | Bugfix: refcounts were getting updated for the wrong ingredients in 'call' instructions.
* 3522Kartik K. Agaram2016-10-191-13/+13
|
* 3520Kartik K. Agaram2016-10-181-1/+0
| | | | | | | | Drop a few debug prints. Hopefully now we need never duplicate trace statements and can instead just dump them to screen. I'll soon need the ability to selectively dump traces for a specific label.
* 3394Kartik K. Agaram2016-09-171-5/+5
|
* 3390Kartik K. Agaram2016-09-171-3/+3
|
* 3389Kartik K. Agaram2016-09-171-11/+11
|
* 3385Kartik K. Agaram2016-09-171-62/+62
|
* 3381Kartik K. Agaram2016-09-171-1/+1
|
* 3374Kartik K. Agaram2016-09-161-1/+1
|
* 3335Kartik K. Agaram2016-09-111-11/+20
| | | | | | | | Clean up rest of long-standing bit of ugliness. I'm growing more confident now that I can use layers to cleanly add any functionality I want. All I need is hook functions. No need to ever put '{' on their own line, or add arguments to calls.
* 3334Kartik K. Agaram2016-09-111-6/+5
| | | | Clean up one long-standing bit of ugliness.
* 3264Kartik K. Agaram2016-08-271-0/+1
| | | | | | Turns out chessboard.mu started deadlocking in commit 3258 even though all its tests continue to pass. Not fixed yet; first make deadlock easier to diagnose.
* 3262Kartik K. Agaram2016-08-271-1/+5
|
* 3259Kartik K. Agaram2016-08-261-1/+1
| | | | | | | | | | | Prefer preincrement operators wherever possible. Old versions of compilers used to be better at optimizing them. Even if we don't care about performance it's useful to make unary operators look like unary operators wherever possible, and to distinguish the 'statement form' which doesn't care about the value of the expression from the postincrement which usually increments as a side-effect in some larger computation (and so is worth avoiding except for some common idioms, or perhaps even there).
* 3258Kartik K. Agaram2016-08-261-0/+1
| | | | | | | | | | | | | In the process of debugging the last couple of commits (though I no longer remember exactly how) I noticed that 'wait-for-routine' only waits until the target routine stops running for any reason, including when it blocks on something. That's not the synchronization primitive we want in production code, even if it's necessary for some scenarios like 'buffer-lines-blocks-until-newline'. So we rename the old 'wait-for-routine' primitive to 'wait-for-routine-to-block', and create a new version of 'wait-for-routine' that say callers of 'start-writing' can safely use, because it waits until a target routine actually completes (either successfully or not).
* 3216Kartik K. Agaram2016-08-171-1/+31
| | | | | | | | | | | | | | | | | | | Another hole in refcount management, which I noticed while doing commit 3202, and thinking about which led to the insight of commit 3212. Now the summary of commit 3197 is modified to this: Update refcounts of products after every instruction, EXCEPT: a) when instruction is a non-primitive and the callee starts with 'local-scope' (because it's already not decremented in 'return') OR: b) when instruction is primitive 'next-ingredient' or 'next-ingredient-without-typechecking', and its result is saved to a variable in the default space (because it's already incremented at the time of the call)
* 3212 - bugfix in refcount managementKartik K. Agaram2016-08-171-24/+0
| | | | | | | | | | | When updating refcounts for a typed segment of memory being copied over with another, we were only ever using the new copy's data to determine any tags for exclusive containers. Looks like the right way to do refcounts is to increment and decrement separately. Hopefully this is a complete fix for the intermittent but non-deterministic errors we've been encountering while running the edit/ app.
* 3204Kartik K. Agaram2016-08-161-1/+4
| | | | Fix CI.
* 3202 - bugfix: 'start-running' and refcountsKartik K. Agaram2016-08-161-0/+59
| | | | | | | | | | | | | | | | | | | | | | When you pass an ingredient to a recipe using 'start-running' it mostly behaves identically to performing a regular function call. However, if the calling function completed before the new routine had a chance to run, the ingredients passed in ran the risk of being reclaimed. In response, let's always increment refcounts at the time of a function call rather than when the ingredients are read inside the callee. Now the summary of commit 3197 is modified to this: Update refcounts of products after every instruction, EXCEPT: a) when instruction is a non-primitive and the callee starts with 'local-scope' (because it's already not decremented in 'return') OR: b) when instruction is primitive 'next-ingredient' or 'next-ingredient-without-typechecking'
* 3201Kartik K. Agaram2016-08-161-0/+1
|
* 3192Kartik K. Agaram2016-08-161-28/+0
|
* 3154 - reorg before making 'random' more testableKartik K. Agaram2016-07-271-0/+625