about summary refs log tree commit diff stats
path: root/053recipe_header.cc
Commit message (Collapse)AuthorAgeFilesLines
* 4134 - 'input' = 'ingredient'Kartik K. Agaram2017-12-031-1/+1
|
* 4104Kartik K. Agaram2017-11-031-4/+4
| | | | | Stop hardcoding Max_depth everywhere; we had a default value for a reason but then we forgot all about it.
* 4091Kartik K. Agaram2017-10-291-1/+1
|
* 4089Kartik K. Agaram2017-10-221-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clean up how we reclaim local scopes. It used to work like this (commit 3216): 1. 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) 2. If a function starts with 'local-scope', force it to be reclaimed before each return. However, since locals may be returned, *very carefully* don't reclaim those. (See the logic in the old `escaping` and `should_update_refcount` functions.) However, this approach had issues. We needed two separate commands for 'local-scope' (reclaim locals on exit) and 'new-default-space' (programmer takes charge of reclaiming locals). The hard-coded reclamation duplicated refcounting logic. In addition to adding complexity, this implementation failed to work if a function overwrites default-space after setting up a local-scope (the old default-space is leaked). It also fails in the presence of continuations. Calling a continuation more than once was guaranteed to corrupt memory (commit 3986). After this commit, reclaiming local scopes now works like this: Update refcounts of products for every PRIMITIVE instruction. For non-primitive instructions, all the work happens in the `return` instruction: increment refcount of ingredients to `return` (unless -- one last bit of ugliness -- they aren't saved in the caller) decrement the refcount of the default-space use existing infrastructure for reclaiming as necessary if reclaiming default-space, first decrement refcount of each local again, use existing infrastructure for reclaiming as necessary This commit (finally!) completes the bulk[1] of step 2 of the plan in commit 3991. It was very hard until I gave up trying to tweak the existing implementation and just test-drove layer 43 from scratch. [1] There's still potential for memory corruption if we abuse `default-space`. I should probably try to add warnings about that at some point (todo in layer 45).
* 4086 - back to cleaning up delimited continuationsKartik K. Agaram2017-10-181-1/+1
|
* 3877Kartik K. Agaram2017-05-261-4/+4
|
* 3876Kartik K. Agaram2017-05-211-7/+14
| | | | Thanks Ella Couch for reporting this issue.
* 3833Kartik K. Agaram2017-04-181-2/+6
| | | | Loosen type-checking slightly to accomodate type abbreviations.
* 3802 - more accurate sandbox resultsKartik K. Agaram2017-03-201-1/+2
| | | | Thanks Lakshman Swaminathan for reporting this issue.
* 3752 - fix a couple of segfaultsKartik K. Agaram2017-03-021-3/+21
| | | | Thanks Ella Couch for running into these.
* 3744Kartik K. Agaram2017-02-071-1/+1
| | | | | | Undo 3743. Really any time we create new instructions from whole cloth during rewriting or transform, the whole notion of 'original name' goes out the window. Pointless trying to fight that fact of life.
* 3743Kartik K. Agaram2017-02-071-1/+1
| | | | | | | | One way to ensure we always set old_name is to create a method to initialize names as opposed to just assigning them. Still not ideal because we still assign directly most of the time, so it's easy to forget.
* 3657 - better error messageKartik K. Agaram2016-11-101-0/+10
| | | | Thanks Ella Couch for reporting this.
* 3656Kartik K. Agaram2016-11-101-13/+13
| | | | | | | | | | | | | | 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.
* 3598 - 'use before set' errors were too crypticKartik K. Agaram2016-10-271-1/+1
|
* 3587Kartik K. Agaram2016-10-241-0/+9
| | | | Another CI fix.
* 3576Kartik K. Agaram2016-10-231-0/+28
| | | | More helpful messages when people forget 'load-ingredients'.
* 3555Kartik K. Agaram2016-10-221-1/+1
|
* 3554 - flag unexpected header for recipe 'main'Kartik K. Agaram2016-10-221-0/+43
| | | | | | As long as Mu operates atop Unix, we need to make these assumptions. Thanks Ella Couch for finding this loophole.
* 3541Kartik K. Agaram2016-10-211-3/+1
|
* 3539Kartik K. Agaram2016-10-211-0/+10
| | | | | | | | | | | | | Always check if next_word() returned an empty string (if it hit eof). Thanks Rebecca Allard for running into a crash when a .mu file ends with '{' (without a following newline). Open question: how to express the constraint that next_word() should always check if its result is empty? Can *any* type system do that?! Even the usual constraint that we must use a result isn't iron-clad: you could save the result in a variable but then ignore it. Unless you go to Go's extraordinary lengths of considering any dead code an error.
* 3522Kartik K. Agaram2016-10-191-20/+20
|
* 3437Kartik K. Agaram2016-10-041-0/+1
| | | | | | | | Drop an ancient case of premature optimization: skipping transform for recipes without bodies. These days recipes also have headers that need transforming. Thanks Caleb Couch for running into this issue.
* 3393Kartik K. Agaram2016-09-171-3/+2
|
* 3390Kartik K. Agaram2016-09-171-1/+1
|
* 3389Kartik K. Agaram2016-09-171-2/+2
|
* 3385Kartik K. Agaram2016-09-171-37/+37
|
* 3379Kartik K. Agaram2016-09-171-2/+2
| | | | Can't use type abbreviations inside 'memory-should-contain'.
* 3341Kartik K. Agaram2016-09-121-0/+22
| | | | | | | Process type abbreviations in function headers. Still a couple of places where doing this causes strange errors. We'll track those down next.
* 3324 - completely redo type abbreviationsKartik K. Agaram2016-09-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The old approach with '&' and '@' modifiers turned out to be a bad idea because it introduces notions of precedence. Worse, it turns out you want different precedence rules at different times as the old test alluded: x:@number:3 # we want this to mean (address number 3) x:address:@number # we want this to mean (address array number) Instead we'll give up and focus on a single extensible mechanism that allows us to say this instead: x:@:number:3 x:address:@:number In addition it allows us to shorten other types as well: x:&:@:num type board = &:@:&:@:char # for tic-tac-toe Hmm, that last example reminds me that we don't handle abbreviations inside type abbreviation definitions so far..
* 3120Kartik K. Agaram2016-07-211-4/+4
| | | | | | | | Always show instruction before any transforms in error messages. This is likely going to make some errors unclear because they *need* to show the original instruction. But if we don't have tests for those situations did they ever really work?
* 3062Kartik K. Agaram2016-06-191-0/+4
|
* 2990Kartik K. Agaram2016-05-201-6/+6
| | | | | | | | | | Standardize quotes around reagents in error messages. I'm still sure there's issues. For example, the messages when type-checking 'copy'. I'm not putting quotes around them because in layer 60 I end up creating dilated reagents, and then it's a bit much to have quotes and (two kinds of) brackets. But I'm sure I'm doing that somewhere..
* 2987Kartik K. Agaram2016-05-201-0/+492
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-14 12:04:26 +0000