| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
On reflection I think I'd rather add a duplicate test that's closer to
how I discovered the problem, without the masking bug in type-matching
that was masking the simpler test in the previous commit.
|
| |
|
|
| |
Thanks Caleb Couch for finding and reporting this.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Thanks Ella and Caleb for finding this.
|
| |
|
|
|
|
|
|
|
|
|
| |
I'd started using size_of() in transforms at some point, but not gotten
around to actually updating it to support arrays before run-time. Wish
there was a way I could statically enforce that something is only called
at transform time vs runtime.
Thanks Ella and Caleb Couch for finding this issue. Static arrays are
likely still half-baked, but should get a thorough working-over in
coming weeks.
|
| |
|
|
| |
Issue 1 in 2829 is now fixed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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..
|
| | |
|
| |
|
|
|
|
|
| |
Current plan:
- get rid of get-address and index-address, and therefore any address
that is not address:shared
- rename address:shared to just 'shared'
|
| | |
|
| | |
|
| |
|
|
|
| |
Undo commit 9da3fc3118; looks like we don't need it anymore, and the
test was poorly done. Let's see if we hit the error again.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Move all bounds checks for types and recipes to one place.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I realize that there's still a serious problem with refcounts.
Everything's fine as long as I copy those shared addresses manually
elsewhere, but there's a couple of places where I just do a memcopy
right now without any extra smarts: in 'copy' and 'merge' instructions.
I need to replace support for arbitrary types in these instructions, and
replace it with transforms to generate the right code. Mu basically
needs copy constructors and destructors, so that containers can
decrement the refcounts of any elements (or elements of elements, or
elements of elements of elements..) that are shared addresses.
But my confidence in this whole approach is shaken. Maybe I should stop
this project. It's turning into a language+OS design project where I was
hoping that being a toy would shelter me from these concerns. I just
want to explore turning manual tests into reproducible automatic ones.
Maybe I should just build libraries for each interface to hardware
(network, disk, screen, keyboard, ...) in C++11 or something. Use no
high-level libraries for sockets, files, etc. Instead rely on just the
kernel syscalls, memory allocator, RAII, STL. Build things from scratch
atop those building blocks.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Thanks Caleb for finding this. Repeatedly running sandboxes was in some
reliably reproducing situations causing 'new' to return 1, or to run
into writes to the free list.
No test yet; the issue is likely only mitigated at this point, not
fixed. Even if routines share the Free_list, that should probably not
cause memory corruption.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This brings back some of the complexity I thought I'd gotten rid of in
2799.
The regression brought home the point that I'd forgotten to write tests
for those bits. Written now.
It also brought home the point that our cleanup in 'reload' has always
been hacky and incomplete.
It's also ugly that those tests in the sandbox/ and edit/ apps need
changing (particularly when the test is about how the output doesn't
change).
|
| |
|
|
| |
Fix test failures caused by 2804 in sandbox/ app.
|
| |
|
|
|
| |
Now to extend 'stash' for arrays, just extend array-to-text-line instead
and perform the lookup inside it.
|
| |
|
|
|
| |
Show more thorough information about instructions in the trace, but keep
the original form in error messages.
|
| |
|
|
|
| |
Don't let rewrite_stash transform working programs into non-working
ones.
|
| |
|
|
| |
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..
|
| | |
|