| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Phew!
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Turns out one of my chessboard tests has been silently deadlocking and
therefore not actually checking its results since at least commit 1620
last June.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Only apps left now, and the wait-for-location uses in the channel
primitives.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|