assets/developer-notes/stephanie-gawroriski/2016/04/30.mkd

   1 # 2016/04/30
   2
   3 ## 00:03
   4
   5 Thinking about it, when performing mass class movearounds, the error code
   6 prefixes can get out of sync. It can also be confusing as to which codes
   7 belong to what. When a stack trace is printed however, the source would be
   8 known. However, I believe for future use that the error codes should be fixed
   9 similar to how I use it now. So if I go through every package, I start at AA
  10 and go all the way through ZZ until things are reached. This way there is no
  11 bias in letter selection. That still gives me about 676 unique codes.
  12
  13 ## 00:48
  14
  15 This splitting and moving around of the `extra` packages will result in smaller
  16 fragments which are easier to split. There might be something needed in the
  17 extra I/O, however it might not need everything which would bring in pointless
  18 dependencies.
  19
  20 ## 00:59
  21
  22 Instead of a `BitCompactor` I can instead have a `BitOutputStream` which can
  23 write bits to an output stream.
  24
  25 ## 01:05
  26
  27 The extra collections could end up being replaced also. Instead of using
  28 `MissingCollections`, it could just be `of` or `new`.
  29
  30 ## 11:18
  31
  32 Going to implement the CRC32 check for ZIP files and such. However right now
  33 I am going to deprecate the generic circular buffer and the related classes
  34 so that they are instead single classes. This would be much faster as there
  35 would be less method call overhead and such.
  36
  37 ## 11:56
  38
  39 Thinking about it, `DataPipe` could combine a `DataSink` and a `DataFaucet`
  40 to create the pipe.
  41
  42 ## 12:54
  43
  44 This `DataSink` is rather nice though. When I write the faucet end of the
  45 code and then merge the two together to form a new pipe, it should be much
  46 cleaner than before. For example calculating the CRC32 will use a data sink
  47 while inflate will use the pipe as it currently does. Also having single
  48 classes for the three should make state easier to be checked. For example, I
  49 do not permit bytes to be accepted unless processing is being performed.
  50
  51 ## 13:46
  52
  53 The faucet end, there will be `fill` to add bytes to the output and then
  54 `drain` which is used by others to obtain the filled bytes.
  55
  56 ## 17:53
  57
  58 Now that the faucet code is complete I can modify the pipe code to use that
  59 instead and then eventually that would mean that the inflate pipe would be
  60 changed also. Then after that an input stream for the data faucet.
  61
  62 ## 17:55
  63
  64 Likely also the input/output streams which wrap sinks and faucets should share
  65 the lock of the faucet it wraps so that there is a kind of thread safety used
  66 when they are wrapped.
  67
  68 ## 18:52
  69
  70 Now the interesting part will be handling the singular state of the sinks and
  71 faucets so that they do not trigger any pipe processing errors. Will be
  72 interesting.
  73
  74 ## 19:09
  75
  76 Well this may be confusing. The code currently goes into the faucet for
  77 processing to read output bytes. However the data sink has to be handled. But
  78 I should just be able to flush the sink.
  79
  80 ## 19:23
  81
  82 Appears that I am deadlocking somewhere.
  83
  84 ## 19:28
  85
  86 Actually caused by the overzealous data pipe input stream. When there is
  87 nothing to read it just reads in all of the input and pipes it in. That would
  88 require much memory to be used.
  89
  90 ## 19:57
  91
  92 Seems like the pipe reads quite a number of input but just stops when nothing
  93 is really left.
  94
  95 ## 20:06
  96
  97 It seems as if the input completion state is never triggered at all.
  98
  99 ## 21:06
 100
 101 Actually, I never set the output as done.
 102
 103 ## 21:42
 104
 105 Actually for the data sink, I need to handle the actual final byte which
 106 would return -1.
 107
 108 ## 22:17
 109
 110 Well having processing be performed regardless gives me AC05.
 111
 112