So far only openarray[int8] worked. Now it's openarray[int8|uint8]. This
should make sense, since uint8 is comfortable to represent a byte
(0-255) and there is already type byte* = uint8 in system.
If you specify a len like 32 toHex() will repeat the given value in the
output. Besides that I believe my implementation is easier and seems not
to change how negative numbers are handled. I also handle the case of
wrapping negative number beyond BiggestInt to "do it right".
Extract maybe re-hash/re-search and insert logic into a new template.
Use this new template to do impl templates for all three put forms
(which required renaming a couple 'value' arguments to 'val').
Added OrderedTable and OrderedTableRef versions of both as well.
Make similar changes to those made in sets.nim, including hcode, rightSize
rawGet/rawGetKnownHC result protocol, nextTry probe sequence to be the cache
friendlier h=h+1 which in turn allows supporting changing deletion to fix the
infinite loop bug with local rehashing which in turn has desirable properties
of graceful table aging when deletes do happen and also making insert-only
usage patterns no longer pay any time/space cost to check deleted status.
Unlike collections.sets, this module has add() for duplicate key inserts and
a 3rd type of table, CountTable. The first wrinkle is handled by introducing
a rawGetDeep for unconditionally adding entries along collision chains. This
point of CountTable seems to be space efficiency at 2 items per slot. These
changes retain that by keeping the val==0 => EMPTY rule and not caching hash
codes. putImpl is expanded in-place for CountTable since the new putImpl() is
too different. { Depending on table size relative to caches & key expense,
regular Table[A,B] may become faster than CountTable, especially if the basic
count update could be something like inc(mGetOrPut(t, key, 0)). }
Unit tests pass, but in this module those are much more of just a demo than
probing for bugs. Should exercise/test this a little more before merging.
I got warning about deprecated names here. I also know that other names probably need to change (T/P prefixes) but I am unsure about the exact rules. I may do that later if you like.
I don't know if the (15|16...) is supposed to work on OSX. I have "libmysqlclient.18.dylib" in my lib directory and get "could not load: libmysqlclient.(15|16|17[18).dylib" on execution. After removing the pattern I can run my little example program and it works as "libmysqlclient.dylib" is a softlink to the current version anyway.
