Looks like the tail is not being set properly for an add operation or after a remove. The tail points to valid data and not 00.


Ok so with a block size of 8:

[H6e  54  65  73 T74  69  6e  60][H00  6e  6e  6e T55  00  00  00]

And a block size of 16:

[H00  54  65  73  74  69  6e  67  54  54  65  73  74  69 T6e  00]

I should probably avoid writing code when half asleep with a headache. So from the looks of it at the trailing block edge it gets erased to zero, perhaps with every read. Since I clear the data that should be the cause of losing a byte. Also, the sequence 6e 6e 6e is kind of odd. So just in case a block size of 32 results in the same data as the one for 16. Notice how 6e is at the end of the other block.


Had some variable confusing checking the removal code. A case where the first block is full and is the only block (there are exactly block size bytes in a block), then the tail would be zero. So if the head was also zero or greater than the tail, it could cause a negative value.


So now the first add is this (previously before the last one):

[H0b  49  2d T2e  c9  cc  4b  0f][H81  50  00 T00  00  00  00  00]

And the block size of 16

[H0b  49  2d  2e  c9  cc  4b  0f  81  50  00 T00  00  00  00  00]

So now the data is consistent.


And now removeFirst should be fixed because the inflate algorithm works for a simple sequence, must check the others. D fails with an IOOB.


Seems the sliding window get is off by 8 or so. While in the inflate test it is only off by 1. So likely the array-like get in ByteDeque is incorrect.


So the sliding byte window tests pass, but now the decompression code just returns a single byte.


Checking revision f429555e874c7819c0fd8370f72bffd3df3ffb43. Fossil's fuse feature is quite nice. That revision fails. Now checking 2d060afcff8466b373b4c246e7e9d723afee7894 and that revision works. The diff is quite simple. The code was replaced by two method calls, get followed by delete. The code is very much the same or the most part.


However test D for that revision fails.


A block size of 16 also fails. However, a block size of 2 causes an exception so I must investigate this.


Took a rest. Check delete, that appears to be fine, it appears the problem is in get.

DEBUG -- GET 0 0 1 0b
DEBUG -- 98fd0c20 in=false T=11 h=0 t=3
DEBUG -- [H0b  49  2d T2e][Hc9  cc  4b T0f][H81  50  00 T00]
DEBUG -- GET 0 1 1 00
DEBUG -- 98fd0c20 in=false T=10 h=1 t=3
DEBUG -- [ 00 H49  2d T2e][ c9 Hcc  4b T0f][ 81 H50  00 T00]

The second set, the vlaue should be 49 and not 00. The "useless" addition that I removed before actually has a purpose. And now it works. Interesting that the code worked for much longer after it was removed. So essentially it was correct code that caused the same thing to happen despite being incorrect.


Now I need to determine if removing DBB and using BD for everything was worth it. I need to see how fast the decompression algorithm runs. I do hope it is faster. And the result is that it is pretty much the same speed as before. It still remains as slow once 32KiB is reached.


Something that might work better is from getting from the end if the address is higher than half of the buffer.


Something that might work better is having an extra list (an ArrayList) which is then used to access the data. Basically, the ArrayList when a block is added at the end, can just be given the block which was added easily. However, when a block is removed from the start it requires recalculation. One issue with an ArrayList is moving values around in the list although when it is not linked it would be easier to work with and use less allocations. So I really just need a kind of virtual ring buffer of sorts. However on generic queue operations it can get complex.