00:03
Thinking about it, when performing mass class movearounds, the error code prefixes can get out of sync. It can also be confusing as to which codes belong to what. When a stack trace is printed however, the source would be known. However, I believe for future use that the error codes should be fixed similar to how I use it now. So if I go through every package, I start at AA and go all the way through ZZ until things are reached. This way there is no bias in letter selection. That still gives me about 676 unique codes.
00:48
This splitting and moving around of the extra packages will result in smaller
fragments which are easier to split. There might be something needed in the
extra I/O, however it might not need everything which would bring in pointless
dependencies.
00:59
Instead of a BitCompactor I can instead have a BitOutputStream which can
write bits to an output stream.
01:05
The extra collections could end up being replaced also. Instead of using
MissingCollections, it could just be of or new.
11:18
Going to implement the CRC32 check for ZIP files and such. However right now I am going to deprecate the generic circular buffer and the related classes so that they are instead single classes. This would be much faster as there would be less method call overhead and such.
11:56
Thinking about it, DataPipe could combine a DataSink and a DataFaucet
to create the pipe.
12:54
This DataSink is rather nice though. When I write the faucet end of the
code and then merge the two together to form a new pipe, it should be much
cleaner than before. For example calculating the CRC32 will use a data sink
while inflate will use the pipe as it currently does. Also having single
classes for the three should make state easier to be checked. For example, I
do not permit bytes to be accepted unless processing is being performed.
13:46
The faucet end, there will be fill to add bytes to the output and then
drain which is used by others to obtain the filled bytes.
17:53
Now that the faucet code is complete I can modify the pipe code to use that instead and then eventually that would mean that the inflate pipe would be changed also. Then after that an input stream for the data faucet.
17:55
Likely also the input/output streams which wrap sinks and faucets should share the lock of the faucet it wraps so that there is a kind of thread safety used when they are wrapped.
18:52
Now the interesting part will be handling the singular state of the sinks and faucets so that they do not trigger any pipe processing errors. Will be interesting.
19:09
Well this may be confusing. The code currently goes into the faucet for processing to read output bytes. However the data sink has to be handled. But I should just be able to flush the sink.
19:23
Appears that I am deadlocking somewhere.
19:28
Actually caused by the overzealous data pipe input stream. When there is nothing to read it just reads in all of the input and pipes it in. That would require much memory to be used.
19:57
Seems like the pipe reads quite a number of input but just stops when nothing is really left.
20:06
It seems as if the input completion state is never triggered at all.
21:06
Actually, I never set the output as done.
21:42
Actually for the data sink, I need to handle the actual final byte which would return -1.
22:17
Well having processing be performed regardless gives me AC05.