- fix premake args being incorrect
- remove platform assumptions, making it portable
- start with a best guess based on project layout
- use fallback if not specified or not found
- display errors/help if not found
hashBits() is used to generate a hash code from the same 64 bits used
to represent a Wren number as a double. When building a map containing
a large number of integer keys, it's important for this to do a good
job scattering the bits across the 32-bit key space.
Alas, it does not. Worse, the benchmark to test this happens to stop
just before the performance falls off a cliff, so this was easy to
overlook.
This replaces it with the hash function V8 uses, which has much better
performance across the numeric range.
With the latest XCode it looks like 32 bit builds are deprecated. This
causes build warnings which fail the libuv build. This commit remvoves
the 32 bit arch from the macOS libuv build, and stops building the 32
build on Travis.
This doesn't let you arbitrarily call back into the VM from within
foreign methods. I'm still not sure if that's even a good idea since
God knows what that would mean if you switch fibers while doing that.
But this does allow the very important use case of being able to call
a foreign method from within a call to wrenCall(). In other words,
foreign methods need to always be leaf calls on the call stack, but the
root of that stack can now come from runInterpreter() or wrenCall().
Fix#510.
- copies files in doc/site/static/ to output
- update output formatting to include potential differences in markdown generator (local generate had >, so cover both to remain consistent)
- copy rss xml (could be in static too, but for now...)
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.
The amalgamation script now searches for files in the different
directories of src.
Also the full paths in the amalgamation were replaced by the basename
to produce the same content on all machines.
The makefile now creates the build directory for the amalgamation
if it does not exist.
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.
