| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Next I'll start improving it.
|
| |
|
|
|
|
|
|
|
| |
Several times now I've wasted time tracking down a failing test only to
eventually remember that order of definition matters in tests even
though it doesn't elsewhere -- I've been having tests implicitly start
running the first function defined in them. Now I stop doing that if a
test defines a function called 'main', and just start the test at main
instead.
|
| |
|
|
|
|
|
|
| |
As outlined at the end of 2797. This worked out surprisingly well. Now
the snapshotting code touches fewer layers, and it's much better
behaved, with less need for special-case logic, particularly inside
run_interactive(). 30% slower, but should hopefully not cause any more
bugs.
|
| |
|
|
|
|
|
|
|
|
| |
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..
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When I started to make channels generic in 2784, I introduced an
infinite loop when running until just layer 72. This happens because
transform_all() can create new recipes while specializing, and these
were getting added to Recently_added_recipes and then deleted. I didn't
notice until now because layer 91 was clearing Recently_added_recipes
soon after.
Solution: make calls to transform_all after calls to load_permanently
also clear Recently_added_recipes like load_permanently does.
No transforms yet create new types. If they do we'll need to start
handling the other Recently_added_* variables as well.
I should rethink this whole approach of tracking changes to global state
while running tests, and undoing such changes. Ideally I wouldn't need
to manually track changes for each global. I should just encapsulate all
global state in an object, copy it for each test and delete the copy
when I'm done.
|
| | |
|
| |
|
|
|
|
|
|
| |
It turns out that my extensible stash doesn't yet work well in all
situations. If you try to stash an array, you end up trying to create an
array local that's not statically sized -- a no-no.
Bah, just throw it all out.
|
| |
|
|
| |
Arrange for tests to run multiple variants of channel functions.
|
| |
|
|
| |
Finally..
|
| | |
|
| |
|
|
|
|
|
| |
Simplify 2790 by simply not computing any type->value inside
parse_type_tree. It now only generates names, and it turns out the
consumers handle the absence of values anyway. Now parse_type_tree no
longer pollutes the Type_ordinal table with type ingredients.
|
| |
|
|
|
|
|
|
| |
The issue alluded to in the previous 2789 is now fixed. I'm not happy
with my solution, though. I pollute Type_ordinal with type ingredients
in parse_type_tree and simply ignore such entries later on. I'd much
rather avoid the pollution in the first place, but I'm not sure how to
do that..
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Why do earlier unit tests start to fail if I load chessboard.mu fail
after correcting the definition of new-channel to be properly generic? I
have narrowed it down to a manual test but am still struggling to turn
it into a scenario.
It looks like the 'new' instruction is the culprit:
first transform:
load a recipe containing a call to new with a generic type
parse_type_tree is called, and pollutes the Type_ordinal table with the generic type
second transform:
load a generic container containing the same generic type ingredient
it fails to be detected as a generic type ingredient
To reproduce, compare these two commands:
mu test
mu test z.mu
|
| | |
|
| |
|
|
|
|
| |
*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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Automate this manual test I've been using.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Ensure we consistently use the same CFLAGS in all invocations of mu from
test_all_layers.
|
| |
|
|
| |
This should eradicate the issue of 2771.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Turns out that LLVM/Clang still doesn't support multiplying 64-bit
numbers on a 32-bit platform.
https://llvm.org/bugs/show_bug.cgi?id=14469
This is just a quick fix, because it turns out I don't have any integer
multiplication anywhere else. In the long run I think I'm going to just
drop 'long long int' in favor of 'int'. Overflow is less likely than
this configuration on somebody's machine.
|
| |
|
|
|
| |
I'm now running valgrind on my Linux server rather than my Mac laptop.
Little less convenient; let's see how it goes.
|
| | |
|
| |
|
|
| |
Need to start testing every commit on Linux in addition to Mac.
|
| |
|
|
|
|
| |
This uncovered a second bug (besides 2766) -- I was manually doing the
work of 'new-fake-console' inside 'assume-console' but forgetting to
increment a refcount.
|
| | |
|
| |
|
|
|
| |
Get rid of a local variable that was only serving to render unreadable
the code for reclaiming allocated memory.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Clean up tangle/ helper.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|