The VM used to not detect this case. It meant you could get into a
situation where another fiber's caller had completed. Then, when it
tried to resume that fiber, the VM would crash because there was nothing
to resume to.
This is part of thinking through all the cases around re-entrancy. Added
some notes for that too.
There's a lot of changes here and surely some rough edges to iron out.
Also, I need to update the docs. But I want to get closer to landing
this so I can build on it.
A statement like:
for (i in 1..2)
When run in the REPL declares a local variable ("i"), but not inside
a function or method body. This hit a corner case in the compiler
where it didn't have the correct slot indexes set up.
That corner case is because sometimes when you compile a chunk, local
slot zero is pre-allocated -- either to refer to "this" or to hold the
closure for a function so that it doesn't get GCed while running. But
if you're compiling top-level code, that slot isn't allocated. But top
level code for the REPL *should* be, because that gets invoked like a
function.
To simplify things, *every* compiled chunk now pre-allocates slot zero.
That way, there are fewer cases to keep in mind.
Also fixed an issue where a GC during an import could collected the
imported module body's closure.
Fix#456.
This is a breaking change because existing imports in user Wren code
that assume the path is relative to the entrypoint file will now likely
fail.
Also, stack trace output and host API calls that take a module string
now need the resolved module string, not the short name that appears in
the import.
This is just for the VM's own internal use, for resolving relative
imports.
Also added a tiny unit test framework for writing tests of low-level
C functionality that isn't exposed directly by the language or VM.
This is an interim step towards supporting relative imports. Previously,
the IMPORT_VARIABLE instruction had a constant string operand for the
import string of the module to import the variable from. However, with
relative imports, the import string needs to be resolved by the host
all into a canonical import string. At that point, the original import
string in the source is no longer useful.
This changes that to have IMPORT_VARIABLE access the imported ObjModule
directly. It works in two pieces:
1. When a module is compiled, it ends with an END_MODULE instruction.
That instruction stores the current ObjModule in vm->lastModule.
2. The IMPORT_VARIABLE instruction uses vm->lastModule as the module to
load the variable from. Since no interesting code can execute between
when a module body completes and the subsequent IMPORT_VARIABLE
statements, we know vm->lastModule will be the one we imported.
This is simpler and marginally faster. We don't need the overhead of
fibers since you can't have long or recursive import chains anyway.
More importantly, this makes the behavior more well-defined when you do
things like yield from an imported module. (Not that you should do that,
but if you do, it shouldn't do weird things.)
If the function the fiber is created from takes a parameter, the value
passed to the first call() or transfer() gets bound to that parameter.
Also, this now correctly handles fibers with functions that take
parameters. It used to leave the stack in a busted state. Now, it's a
runtime error to create a fiber with a function that takes any more
than one parameter.
These lazy iterator producing methods are useful when working with
arbitrary sequences and you need to skip or take some number of elements
at the start.
They were inadvertently relying on undefined behavior in C and we get
different results on some compilers.
Until we decide how we want the operation to behave, for now, just
leave it unspecified.
The current behavior is undefined in C when converting the double to a
u32, so the tests fail on some compilers. For now, I'm just removing
those parts of the tests because I'm not sure what I want the behavior
to be. Modulo? Truncate? Runtime error?
Build Wren for more targets, and run the test suite on both 32 and 64
bit builds.
* Update the build config to test both with and without NAN_TAGGING
defined.
* Updatest `util/test.py` to take the executable suffix as a
parameter. This allows the makefile to control which binaries will be
tested.
Adds a new target to the makefile to be run by travis, this runs the
test suite against all of the configurations it builds.
* Gcc on some 32 bit platforms was complaining about numeric overflows
when -INFINITY was used. Update the logic for converting a double to
a string to not explicitly check against the literal values.
* Make CI builds run the tests on both 64 _and_ 32 bit builds.
* If I limit the number of CPUs on my MBP I can get some of the tests
to time out, I'm imagining that the specs of the Travis Macs means
that the same is happening there too. Updated the test script to
allow an extra few seconds for the test to complete successfully
before killing it.
* Due to slight differences in accuracy in some computations tests were
failing on 32 bit builds. Stop comparing things quite as exactly in
the cases where it is causing issues.
For some reason 12.34 was refusing to compare equal to itself. Bad
show 12.34 :-/. I've also updated the test so it doesn't leak handles
even if the assertions fail.
* Double-cast from `double` to `uint32_t` to prevent undefined
behaviour on overflow of basic integers. This should hopefully
prevent 32 bit test failures on Linux.
* Move to a version of LibUV with a fix for the 32 bit build error on
Travis.
- Remove List.new(_). I was convinced by the issue discussion that
using it is probably a bad idea. We don't want to encourage more nulls
in the world than there are already are. So let's see if we can live
without it and just have List.filled(). That way users think about
what they're creating a list *of*.
- Added some more tests.
- Correctly handle being given a negative size.
