| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
There's still a problem: if I ever want to use any of the special
scenario variables like 'screen', 'console', etc., then I can't use
'local-scope' in my scenario.
|
| |
|
|
|
|
|
|
|
|
|
| |
Turns out we don't need a primitive to return an empty value of
arbitrary type. Just create it on the heap using 'new'.
But this uncovered *yet* another bug, sigh. When I specialize generic
functions I was running all transforms on the generated functions after
specialization completed. But there's one transform that includes code
from elsewhere. If such code included type-ingredients -- kaboom. Now
fixed and there's a test, so I've got that going for me which is nice.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was an interaction between two transforms. The first turned:
return-if ...
into:
jump-unless ..., 1:offset # skip next instruction
return ...
The second added an unconditional return at the end of the recipe if it
didn't already exist (so that functions always end with a return).
However, it was getting confused by the return instructions generated
above, which look unconditional but sometimes get skipped.
To fix this, conditional returns are now transformed into this:
{
break-unless ...
return ...
}
Since the final instruction is now no longer a reply (but rather the '}'
label), the second transform triggers and adds the unconditional return
after it.
This commit removes the final place marked 'BUG:' in the codebase
yesterday (see commit 2870).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The solution for avoiding deadlock is for routines to close channels
before they exit. So that's good.
Once I implemented 'close', I also found and fixed 2 unrelated bugs in
chessboard.mu:
a) one long-missed and long-masked case of forgetting to store
character literals in character variables
b) one typo in translating get-address to put
So that's good.
What's not so good: in the process of fixing this I've found three
unrelated bugs (marked 'BUG:' in the changes). All three have
workarounds, so existing tests pass for now. But they are my top
priority next.
|
| | |
|
| |
|
|
|
|
|
| |
Now that we no longer have non-shared addresses, we can just always
track refcounts for all addresses.
Phew!
|
| | |
|
| |
|
|
|
|
| |
This reinfoces that it's only really intended to be used by
'wait-for-location'. To reinforce that we also move it to the same layer
as 'wait-for-location'.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
I have a tack now for issue 2 of 2829 (dealing with wait-for-location):
have get-address and index-address return a type that can't be looked
up. That way the worst that can happen with an address pointing to a
freed location is a routine that randomly hangs and starts working
again. And even that won't happen if you disallow transferring the new
type across routines in ingredients or channels, just like I plan to do
with 'address:shared'.
|
| |
|
|
|
|
|
| |
Previously to watch an address we had to perform a lookup of it, which
the instruction then proceeded to undo. This way wait-for-instruction no
longer supports literal ingredients, but the real-world usage becomes
cleaner.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. It turns out we couldn't overload 'get' and 'get-address' until now,
because transform_names looks for those names, and the
resolve_ambiguous_calls transform happens before transform_names. Why
does resolve_ambiguous_calls happen before transform_names? Because if
my students made mistakes in the ingredients to an instruction they got
overzealous errors from resolve_ambiguous_calls. Now this impacts 'put'
as well, which is already overloaded for tables. Not sure what to do
about this; I'm going to go back to the overzealous errors, and just
teach students to visually scan past them for now.
2. I need addresses in a third place besides storing to containers and
arrays, and managing the heap -- to synchronize routines.
wait-for-location requires an address. Not sure what to do about this..
|
| |
|
|
|
|
|
|
|
|
| |
This way when you pass one end to a function or routine, you can
implicitly give it the right to either read or write the channel, but
not both.
The cost: code gets more convoluted, names get more convoluted. You can
see this in particular in the test for buffer-lines. Let's see how it
goes..
|
| |
|
|
| |
Arrange for tests to run multiple variants of channel functions.
|
| |
|
|
| |
Finally..
|
| | |
|
| |
|
|
|
|
| |
*Really* make channels generic. I'd fixed all the call sites in 2785,
but forgotten to actually switch the declaration. It works though;
generics working smoothly.
|
| |
|
|
|
|
| |
I've ignored Mu's concurrency primitives for a while, but they're
starting to return to front-and-center as I work on the file system
interfaces.
|
| |
|