about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 3395Kartik K. Agaram2016-09-1797-4600/+4668
|
* 3394Kartik K. Agaram2016-09-179-43/+49
|
* 3393Kartik K. Agaram2016-09-179-24/+22
|
* 3392Kartik K. Agaram2016-09-174-7/+36
| | | | Bugfix for the "remaining bug" mentioned in commit 3391.
* 3391 - type abbreviations everywhereKartik K. Agaram2016-09-1724-3256/+3256
| | | | | | | | | Well, almost. I can't use them in some places in C++ where I'm just creating a temporary reagent without passing it through transforms. Like in some unit tests. I can't use them in memory-should-contain. And there's one remaining bug: I can't use abbreviations in a couple of places in 075channel.mu.
* 3390Kartik K. Agaram2016-09-1733-240/+240
|
* 3389Kartik K. Agaram2016-09-1745-713/+720
|
* 3388Kartik K. Agaram2016-09-176-56/+56
|
* 3387Kartik K. Agaram2016-09-171-31/+31
|
* 3386Kartik K. Agaram2016-09-177-93/+93
|
* 3385Kartik K. Agaram2016-09-1730-858/+858
|
* 3384Kartik K. Agaram2016-09-171-0/+14
|
* 3383Kartik K. Agaram2016-09-172-4/+4
| | | | Fix overzealous search-and-replace in commit 3380.
* 3382Kartik K. Agaram2016-09-171-5/+5
|
* 3381Kartik K. Agaram2016-09-1725-131/+131
|
* 3380Kartik K. Agaram2016-09-1743-854/+855
| | | | | One more place we were missing expanding type abbreviations: inside container definitions.
* 3379Kartik K. Agaram2016-09-1732-407/+407
| | | | Can't use type abbreviations inside 'memory-should-contain'.
* 3378Kartik K. Agaram2016-09-171-3/+2
|
* 3377Kartik K. Agaram2016-09-176-49/+49
|
* 3376 - start maximally using all type abbreviationsKartik K. Agaram2016-09-176-31/+31
| | | | | | It might be too much, particularly if students start peeking inside .mu files early. But worth a shot for not just to iron out the kinks in the abbreviation system.
* 3375Kartik K. Agaram2016-09-172-4/+5
|
* 3374Kartik K. Agaram2016-09-1615-62/+62
|
* 3373Kartik K. Agaram2016-09-161-1/+2
| | | | | | Commit 3370 fixed the memory leak but it still had print:character printing characters rather than numbers like it used to before 3365. Go back to the old, unambiguous trace.
* 3372Kartik K. Agaram2016-09-161-7/+9
|
* 3371Kartik K. Agaram2016-09-1612-89/+173
|
* 3370Kartik K. Agaram2016-09-161-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix CI. Figuring out this memory leak was an epic story. I was able to quickly track down that it was caused by commit 3365, in particular the overloading of to-text to support characters. But beyond that I was stumped. Why were layer 3's trace_stream::curr_stream objects being leaked in layer 81 by a change in layer 59?! Triaging through the layers, I found the following: layer 81 - leaks 2 blocks (in clear-line-erases-printed-characters) layer 83 - leaks 4 additional blocks (in clear-line-erases-printed-characters-2) I also figured out that the leaks were happening because of the call to 'trace' on a character inside print:character (that's the 'print' function called with a character argument) trace 90, [print-character], c So I tried to create a simple scenario: scenario trace-on-character-leaks [ 1:character <- copy 111/o trace 90, [print-character], 1:character ] But that triggered no leaks. Which made sense because there were plenty of calls to that 'trace' instruction in print:character. The leak only happened when print:character was called from clear-line. Oh, it happens only when tracing 0/nul characters. Tracing a Mu string with a nul character creates an empty C++ string, which is weird. But why should it leak memory?! Anyway, I tried a new scenario at layer 62 (when 'trace' starts auto-converting characters to text) scenario stashing-nul-character-leaks [ 1:character <- copy 0/nul trace 90, [dbg], 1:character ] But still, no leak! I played around with running layers until 70, 80. But then it didn't leak even at layer 82 where I'd seen it leak before. What had I done? Turns out it was only leaking if I used names for variables and not numeric addresses. Eventually I was able to get layer 59 to leak: scenario stashing-nul-character-leaks [ c:character <- copy 0/nul x:text <- to-text c trace 90, [dbg], x ] At that point I finally went to look at layer 3 (I'd been thinking about it before, but hadn't bothered to *actually go look*!) And the leak was obvious. In the end, all the information I needed was right there in the leak report. The reason this was hard to find was that I wasn't ready to believe there could be a bug in layer 3 after all these months. I had to go through the five stages of grief before I was ready for that realization. Final mystery: why was the memory leak not triggered by numeric variables? Because the transform to auto-convert ingredients to text only operated on named variables. Manually performing the transform did leak: scenario stashing-text-containing-nul-character-leaks [ 1:text <- new character:type, 1/capacity put-index *1:text, 0, 0/nul trace 90, [dbg], 1:text ]
* 3369Kartik K. Agaram2016-09-152-24/+0
| | | | Fix some tests and make them less fragile.
* 3368Kartik K. Agaram2016-09-152-15/+4
| | | | Decouple layer 61 test from layer 62 dependency.
* 3367Kartik K. Agaram2016-09-151-8/+24
| | | | | | | | | | | | | | | | | | | | | | Solution to a minor puzzle that came up during today's lesson with Ella: some sandboxes were showing the address of text results, while others were showing their contents. It took a while to realize that the distinction lay in whether the sandbox was saving the results in a text variable: new [abc] => <some address> x:text <- new [abc] => abc It took *much* longer to realize why I couldn't make the first case work like the second. Eventually I realized why: recipes were reclaiming their results if they weren't 'escaping' -- that is, being saved in a variable in the caller so they could be used later. Any solution to this would be a hack, so I'm going to just leave it alone. Type abbreviations should help minimize the extra typing needed to get sandboxes to show text contents.
* 3366Kartik K. Agaram2016-09-151-1/+1
| | | | | | Small bugfix in error messages for scenarios: we're trying to use read_mu_string() on an array of characters rather than an address to an array of characters. So we need to pretend we have a refcount.
* 3365 - create strings out of arbitrary typesKartik K. Agaram2016-09-153-3/+72
| | | | | The implementation is quite hacky. Let's see how future needs develop before we try to clean it up.
* 3364Kartik K. Agaram2016-09-154-9/+17
|
* 3363 - bugfix in tangleKartik K. Agaram2016-09-152-1/+12
|
* 3362Kartik K. Agaram2016-09-151-3/+3
|
* 3361Kartik K. Agaram2016-09-151-7/+7
|
* 3360Kartik K. Agaram2016-09-151-1/+1
|
* 3359Kartik K. Agaram2016-09-151-10/+9
|
* 3358Kartik K. Agaram2016-09-152-0/+9
|
* 3357 - multi-ary 'append'Kartik K. Agaram2016-09-151-33/+36
|
* 3356Kartik K. Agaram2016-09-151-10/+10
|
* 3355Kartik K. Agaram2016-09-1549-980/+1704
|
* 3354 - support multiple routines at a source/sinkKartik K. Agaram2016-09-152-13/+40
| | | | | This commit completes the final step: fixing the final failing tests (in chessboard.mu) by teaching `restart` about the block signal.
* 3353Kartik K. Agaram2016-09-152-7/+65
| | | | | | | | | | | | | Fix failing scenarios in channel layer. We do so by introducing a kludgy new instruction to explicitly signal when a routine is stuck ('blocked') and waiting on another. All this locking and blocking may well be a crap design. We'll see if we find ourselves using these primitives again. Ideally we don't need them for anything else now that we're done building channels. Still some failing scenarios left in chessboard.mu. Let's see how that goes.
* 3352Kartik K. Agaram2016-09-141-72/+72
| | | | | Reorder `wait-for-routine-to-block` to be close to related routines `switch` and `restart`.
* 3351 - new but incomplete synchronization setupKartik K. Agaram2016-09-142-48/+101
| | | | | | | | | | | | | Previously our channels were based on an unconventional `wait-for-location` primitive that waits for a specific address to change its contents. This only works as long as a channel has a single reader and a single writer routine. To support multiple readers and writers we switch to a more conventional compare-and-set primitive. There's still a couple of failing scenarios, though -- the ones using `wait-for-routine-to-block`, because the new approach never blocks on an empty or full channel, just yields CPU for a time before polling. Hmm, how to fix this?
* 3350Kartik K. Agaram2016-09-142-3/+7
| | | | Three separate CI fixes(!)
* 3349Kartik K. Agaram2016-09-141-2/+6
| | | | Fix a warning on some compilers.
* 3348Kartik K. Agaram2016-09-141-4/+20
| | | | | | | | Expand type abbreviations when checking for colliding/redefined variants. This may need a separate transform if we ever find the need to use type abbreviations before defining them.
* 3347Kartik K. Agaram2016-09-134-8/+8
| | | | | | | | | Done using 'text' type abbreviation everywhere. There's still a problem. If we define a function with a type abbreviation and then redefine it without, I think we end up creating separate variants. That seems wrong. Let's isolate a scenario for that next.
* 3346Kartik K. Agaram2016-09-133-9/+14
| | | | Process type abbreviations in *shape-shifting* function headers.