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
