文宇祥
One possible solution is to store colliding entries as a self-balanced binary tree, so worst time complex is `O(log(N))`. But this makes hashmap require `Compare` trait.
Watch mode re-run my persistent task without kill previous job. I'd like it do not re-run persistent tasks. Or allows `turbo run xx watch yy` to do both watch tasks...
In ocamllex and sedlex, `eof` is special pseudo character which value is `-1`. `YYPEEK` returns -1 if it reaches end of input. But it is a challenge in re2c which...
This raises a new question: Should we migrate to Java's name convention for data structures? Like TreeMap, SkipListMap... So `immut/array` goes to `immut/hamt_array`?
Yes, we should print stacktrace at least in debug mode. /cc @Guest0x0
If make this changes: ``` suite.add("ffi:sort", () => { ffi_moonbit_array_sort_int(ffi_test_data) // ffi_moonbit_array_reverse_sort_int(ffi_test_data) }) suite.add("moonbit:sort", () => { mbt_moonbit_array_sort_int(mbt_test_data) // mbt_moonbit_array_reverse_sort_int(mbt_test_data) }) suite.add("javascript:sort", () => { javascript_array_sort_int(js_test_data) // javascript_array_reverse_sort_int(js_test_data) }) ```...
I see there's timsort implementation in core, but only for `FixedArray::stable_sort`. So I created #2595 .
Tested on timsort version ``` ffi:sort x 50.08 ops/sec ±0.33% (66 runs sampled) moonbit:sort x 204 ops/sec ±1.63% (88 runs sampled) javascript:sort x 49.86 ops/sec ±0.70% (66 runs sampled) Fastest...
Tested on timsort_by version ``` ffi:sort x 50.39 ops/sec ±0.26% (67 runs sampled) moonbit:sort x 87.71 ops/sec ±0.10% (77 runs sampled) javascript:sort x 50.47 ops/sec ±0.22% (67 runs sampled) Fastest...