about summary refs log tree commit diff stats
path: root/mu.arc
Commit message (Collapse)AuthorAgeFilesLines
* 337 - rename 'continue' instructions to 'loop'Kartik K. Agaram2014-11-261-10/+10
|
* 336Kartik K. Agaram2014-11-261-1/+0
|
* 335 - tangle at labels scoped to functionsKartik K. Agaram2014-11-261-5/+7
|
* 332 - example function with multiple clausesKartik K. Agaram2014-11-261-0/+2
| | | | | | | | | | | I'm still figuring out the idioms, and it doesn't seem like there's an easy way to avoid redundant allocations and arg reading. At least for generic functions we want to optimize for each call-site, we can create subsidiary labels to jump to. Also, this is the first genuine use for random access to a function's arguments.
* 325 - example program using channelsKartik K. Agaram2014-11-251-0/+1
|
* 323 - function clausesKartik K. Agaram2014-11-241-2/+6
| | | | | | | | | | | You can now call 'def' on a function name multiple times. Each time the instructions you provide are *prepended* to any existing instructions. One important use for this is when you define a new type and need to support it in all your generic methods. Now you can keep all those extensions in one place, near the definition of the type. To redefine a function, use 'def!'.
* 321 - before/after can now come anywhereKartik K. Agaram2014-11-241-7/+9
| | | | | | This pollutes our traces with all 'system software'. Too much trouble to keep it out; just lump it for now. Who knows, might even be useful. Most of the time convert* labels are easy to grep out when debugging.
* 320Kartik K. Agaram2014-11-241-1/+1
|
* 319 - ack, forgot to handle blocks when tanglingKartik K. Agaram2014-11-241-13/+22
| | | | | | | | | | | | Will the 'lightweight tools' really be all that useable if we encourage people to layer them one atop another and track precisely what inputs each can accept? Something to keep an eye on. In the meanwhile, we have a new (but very unrealistic) example demonstrating the tangling directives. There's still a big constraint on ordering: before/after clauses have to come before functions that need them.
* 318Kartik K. Agaram2014-11-241-0/+7
|
* 317Kartik K. Agaram2014-11-241-79/+83
|
* 315 - handle before/after uniformly like defKartik K. Agaram2014-11-241-16/+22
|
* 314 - better syntax for functionsKartik K. Agaram2014-11-241-3/+5
|
* 313 - tangling primitivesKartik K. Agaram2014-11-241-2/+33
|
* 312Kartik K. Agaram2014-11-241-7/+9
|
* 311Kartik K. Agaram2014-11-241-3/+3
|
* 306 - 'sleep' now watches for changes to a locationKartik K. Agaram2014-11-231-21/+8
| | | | | | | | | | | | This simplifies things a lot and eliminates the race condition. I think it's practical too, as long as you save a single location and don't permit sleeping on compound structures. I'm resigned to needing a lock in the native setting. Should I be concerned that I fixed a failing test by getting rid of hit? If I had alternatives, how would I save the old sleep implementation?
* 305 - simplify wakeup to not require routine*Kartik K. Agaram2014-11-231-7/+2
|
* 304 - a unit test for a race conditionKartik K. Agaram2014-11-231-0/+6
| | | | | | | | | | | Still failing, but worth memorializing for posterity. Race condition tests are still experimental, even more tied to a very specific implementation. If I make changes to 'write' the very 'wipe-read' label will go away. But then you just delete all tests relying on stale labels and try to think up new race conditions.
* 302 - now we can add some labels to 'write'Kartik K. Agaram2014-11-231-0/+2
| | | | | | | | The hope is that those labels will help us test the race condition by hooking into the scheduler. Hooking into the scheduler will complicate the task of dropping racket and running tests natively. But we'll worry about that later.
* 301 - yes, close-offset simplifies nicelyKartik K. Agaram2014-11-231-18/+14
|
* 300 - missed a spotKartik K. Agaram2014-11-231-5/+8
| | | | | | Also uncovered a bug in convert-braces, which helps see a simpler close-offset. Instead of all that crap with first incrementing then waiting for counter to return to 0, just wait for counter to go to -1.
* 299 - labels inside functionsKartik K. Agaram2014-11-221-20/+31
|
* 297Kartik K. Agaram2014-11-221-0/+8
|
* 296 - finally, shared a channel between routinesKartik K. Agaram2014-11-221-2/+2
| | | | Was already working, test was just stale. Reassuring.
* 295Kartik K. Agaram2014-11-221-1/+1
| | | | | Too hard to canonicalize routines in traces, with their nested tables. Give up for now.
* 294 - read/write now pass channel by referenceKartik K. Agaram2014-11-221-15/+15
| | | | But handoff test still failing.
* 291 - figured out the channel-handoff problemKartik K. Agaram2014-11-211-3/+8
| | | | | | | | 'read' and 'write' pass in the channel by value, so they block on different *local* variables. Does this kill my plan to pervasively use call-by-value everywhere? No, we might be able to salvage it if channels are the only shared pointers.
* 290 - how was channel-write-block *ever* working?!Kartik K. Agaram2014-11-211-1/+1
| | | | Oh right, because I wasn't using default-scope when checking to wake up.
* 289 - finally back to deadlock detectionKartik K. Agaram2014-11-211-2/+3
|
* 288 - support sleeping while watching a memory locationKartik K. Agaram2014-11-211-1/+2
|
* 287Kartik K. Agaram2014-11-211-19/+21
|
* 286Kartik K. Agaram2014-11-211-5/+7
|
* 285Kartik K. Agaram2014-11-211-2/+1
|
* 284Kartik K. Agaram2014-11-211-9/+9
|
* 283Kartik K. Agaram2014-11-211-20/+20
|
* 282 - scheduler skips ahead when all routines are asleepKartik K. Agaram2014-11-211-26/+32
|
* 281Kartik K. Agaram2014-11-211-26/+21
|
* 280 - waking up sleeping routinesKartik K. Agaram2014-11-211-5/+7
| | | | Tests still hanging at some point.
* 279 - one new test passing, but sleep now hangsKartik K. Agaram2014-11-211-2/+5
|
* 278Kartik K. Agaram2014-11-211-0/+5
|
* 277 - back up, start refactoring the schedulerKartik K. Agaram2014-11-211-32/+55
| | | | | | | | | In trying to share pipes between routines, I realized my scheduler was actually quite brittle. Changing scheduling-interval* shouldn't be required in most tests, and shouldn't change the outcome most of the time. Current state: all scheduler tests fail, but everything else passes.
* 276 - now fork can take any argsKartik K. Agaram2014-11-191-2/+1
| | | | | | | | | No oargs, though. Hopefully we don't need them. Use channels for passing data back. Drawback: channels must all be passed in by value, and their direction isn't obvious. Hard to tell when multiple threads read/write the same channel. Hopefully it's amenable to static analysis.
* 275 - pass args to forkKartik K. Agaram2014-11-191-3/+4
| | | | Only literals for starters.
* 273Kartik K. Agaram2014-11-181-1/+1
|
* 272Kartik K. Agaram2014-11-181-1/+1
|
* 271Kartik K. Agaram2014-11-181-7/+7
|
* 270Kartik K. Agaram2014-11-181-2/+8
|
* 269Kartik K. Agaram2014-11-181-12/+28
| | | | | | Minor cleanup and code comments. I'm starting to feel the need for formatting primitives, so I don't use comments just to provide section headings.
* 267 - more intuitive channel capacityKartik K. Agaram2014-11-151-0/+1
|