It's not supported in C++98. Instead, use isnan() and isinf(), which
seem to work? If nothing else, they are used elsewhere in Wren, so if
we're not going to use them here, we should fix the other places too.
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?
Updates the way we calculate thenext GC to make sure that we're not
already past the threshold. This was causing endless garbage collections
on 32 bit builds in `test/language/deeply_nested_gc.wren`.
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.
Updates the way we calculate thenext GC to make sure that we're not
already past the threshold. This was causing endless garbage collections
on 32 bit builds in `test/language/deeply_nested_gc.wren`.
- 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.
- Rename "size" -> "count" to be consistent with other usage.
- Remove "Slot" from the function names, since that's implicit.
- Make the getListElement() just move the element to another slot. This
matches other APIs where we distinguish accessing a value and
converting it to some specific type.
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
Just pulling the raw words out of a double means integers often map to
hashes with zero low bits. Then when we map that to an entry in the map,
all small integers end up in entry zero, leading to tons of collisions.
This mixes the bits around some like Java does to fix that.
Makes the map_numeric benchmark about 18% faster on my machine. On a
contrived benchmark that just uses keys up to 1000, this makes it 52x
(yes, *times) faster.
Previously, you could get into a state where a key was present in the
map, but after a tombstone in the probe sequence. If they key was added
again, it stopped at the first tombstone and added it there, resulting
in the key being in the map multiple times.
Fix#373.
