10:32
New month.
10:37
So there have been about 440 commits for the entire month, which is not too bad. Although I have yet to reach native code compilation and I had part of an interpreter which I deleted (it was very ugly). The early part of the month was refactoring. I had working inflate code, but my current partial refactor is changing how the code works underneath (datapipe and such). I thought about compiling to C and using GCJ but that would be very ugly. And the last day or so is a refactor of the extra packages that I have.
10:40
So from where I left off, I get an AC0a which means that the dual state of the pipeline was not specifically set when I try reading input bytes from the pipeline. So I propose that if the input is complete and the input pipeline is empty that all reads cause EOF to occur.
10:43
I also get it now in completeOutput
, since the input state may be complete
then output completion may occur if the faucet is being filled.
10:45
And output completion is called twice, but that is the inflate code which I added since nothing was being called.
10:47
Then right now I have truncated output, at least for the very large compressed data set. Well actually it is not truncated, quite a number of the output is missing. Quite a number of zeros are missing from the output. So it seems as if zeros are never recorded in the output. Since my output sink is a single byte it is possible that it is recorded incorrectly when sent to the output that it does not like zero values.
10:51
So the values are sent to the data filler, so then it must be the drain side which is not correct.
10:52
Actually it is the input stream for the data pipe:
// {@squirreljme.error AC0e Forced stall.}
else if (rv == 0)
throw new PipeStalledException("AC0e");
That is discard read zero values and treating them as stall, this would be correct if the read were multiple bytes instead of just one.
10:57
Using zero it can be seen how slow the official pure interpreter is, however my decompression algorithm seems rather fast. So the next speed optimization I can make is rewriting the circular buffers so that they are standalone rather than being part of generic buffers.
11:00
I also can remove potentially MissingCollections
and use the unmodifiable
classes semi-directly instead. So just UnmodifiableSet.<A>of(foo)
instead
of the longer MissingCollections.<A>unmodifiableSet(foo)
. I believe I will
do that first since I must prepare food to cook and changing that would be
simpler than rewriting the circular buffers in a short amount of time.
11:03
I can also move them into their own packages. So just extra-util-unmodifiable
and extra-util-boxed
so that they are part of the same family and such.
11:36
Then after those two, implement the CRC32 algorithm so that ZIP entries are verified.
11:59
Of the things used, the boxed integers and empty collections have not been used at all.
12:36
Real life stuff puts a large dent into refactoring today.
15:22
I walked 8 miles in 2 hours.
16:14
Right now the only thing to implement is offerLast
and removeFirst
.
17:17
The CircularByteBuffer
could just use the DynamicByteBuffer
although there
may be an added inefficiency. However, an improvement in DynamicByteBuffer
could increase the speed of the circular byte buffer, especially if the
dynamic byte buffer becomes like the circular byte buffer more.
17:33
The CircularByteBuffer
is not really circular, it is more of a queue so I
suppose I shall call it that instead.
22:53
Changing the ByteDeque
to use DynamicByteBuffer
despite some speed
limitations of the dynamic byte buffer results in the tests for the deflate
algorithm running a bit faster now. A second is small on this system (which is
quite old), but on an even slower system that second could be 5 minutes.
23:13
Also, the obvious big speed increase would be the removal of insane amounts of
boxing due to the way the generic deque worked. Should also result in less
pointless and quick allocations also. So on more memory constrained systems it
should also be faster. I just now need to implement the boolean side of the
data. I will do something similar and perform a large copy and paste of the
ByteDeque
code but handle a higher precision at the boolean
level.
23:17
The boolean
based version which would use the DynamicByteBuffer
will have
to handle shifts for the head and tail. Much more complex.
23:20
One thing would be to handle the slight offset since the backing store are
bytes rather than booleans. I could write a DynamicBooleanBuffer
but that
would just duplicate the code.