* Flatten object type
* Use separate construct functions
* Use separate gen_*_diff functions
* Remove maptype and seqtype from Diffs
* Preallocate ops in new_map_or_table
* More preallocations
It wasn't really uncompressed as we have compressed and uncompressed
changes in the backend. It is just not encoded into the binary format.
The module separation (protocol vs backend) should help with the
distinction.
This means we can keep things in the original state but while applying
the diff we don't have to keep building a new vec each time.
This makes B1.1 run in ~11 seconds for me.
These were likely used at one point but now just incur an expensive
allocation cost. This reduces the B1.1 Append N characters benchmark
from ~19s to ~16s.
This brings the DiffEdit types more in line with the typescript ones and
fixes the names. Also changed to using match guards in the append_edit
function so we can take edit by value.
* Use grapheme clusters in Text instead of char
char is not what users typically expect as a 'letter' so we should use
grapheme clusters instead. These can't always be represented as single
rust char types so the Text now stores a Vec of single grapheme Strings.
* Add test for grapheme clusters in text
* Use debug_assert_eq instead of debug_assert
* Add failing alignment test case
* Add wasm-pack test to ci
* Box im_rc::Vector contents to satisfy alignment
This makes the frontend not have alignment issues on 32 bit
architectures (e.g. wasm32-unknown-unknown). The box provides a
consistent alignment for the Vector.
* Add test to check save and load works on failing input
We loop 100 times due to it being a flaky test, likely due to an
iteration order issue in hashmaps.
* Update printing diff of changes
* Add new case for save then load
* Add another failing test case for save_load
* Update test case
* Update test case to not use empty strings in keys
* Specify to decode into usize in rle decoder
The `decoder.read` call was previously inferring to use isize since the
`self.count` variable is that type. This meant that for a list of null
values >= 64 in length it would read it as negative and so enter an
infinite loop of reading nulls, even if there were other values to read.
This changes the read to use usize but introduces the issue of usize
potentially being bigger than isize. This should be very unlikely for
what it is currently used for though so I'll defer this to later work.
* Add a test case to check the repeated nulls issue in rle
* Update tests
* Specify reading rle len as i64 instead of isize
