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.
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.
Instead of dynamically downloading these as needed during a build, this
checks in those two dependencies directly into the Wren repo. That's a
little lame because users of Wren who aren't building the CLI don't
actually need them, but they aren't too big, so it's not a huge deal.
It makes builds (particularly on Travis) more reliable, because they
don't have to pull down additional content over the network.
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.
It’s impossible to disable @s in Makefiles to get a verbose build.
Adding them conditionally using a variable lets users choose if they
want a verbose build by using the VERBOSE variable.
Normal build:
make
Verbose build:
make VERBOSE=1
It doesn't actually execute code yet, but it:
- Supports left and right arrow keys for moving the cursor.
- Ctrl-C, Ctrl-D, Ctrl-A, and Ctrl-E for navigating.
- Syntax highlights the line (!).
The next step is to do a rough parse so that we can tell if the line
is an expression, statement, or needs more input. That will tell us
whether we need to interpret it at the top level (statement) and not
worry about a result, evaluate it as an expression and print the result,
or read more lines.
- Add process module with Process class.
- Add "arguments" and "allArguments" methods.
- Docs for same.
- Support passing additional arguments to command line.
- Add "--help" support to command line.
It's failing when building with clang on Travis. The underlying problem
seems to be something broken with how LLVM is looking for the gold
linker, and working around that is outside of my skillset.
To learn more, Google: "LLVMgold.so: error loading plugin" lto
- wrenEnsureSlots()
Lets you go the foreign slot stack to make room for a temporary work
area.
- wrenSetSlotNewList()
Creates a new empty list and stores it in a slot.
- wrenInsertInList()
Takes a value from one slot and inserts it into the list in another.
Still need more functions like getting elements from a list, removing,
etc. but this at least lets you create, populate, and return lists from
foreign methods.
This turns those functions into general-purpose functions for writing
raw C values into slots on the foreign call stack.
Writing a return just means writing a value to slot 0.
I've got some ideas on how to tweak the embedding API, but I want to
see what performance impact they have first, so this adds a little
benchmark that just calls a foreign method a ton of times.
