- 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.
Guesses whether the input is an expression or statement and handles it
appropriately. Finally, after over a year, the Wren REPL automatically
prints "3" if you type in "1 + 2". \o/
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.
There's nothing new in this "release", but now is as good a time as any
to start versioning. Going forward, I plan to do periodic releases and
update the changelog so users can see what's going on.
