assets/developer-notes/stephanie-gawroriski/2016/03/28.mkd

   1 # 2016/03/28
   2
   3 ## 01:39
   4
   5 Figured out what that bl_count means.
   6
   7 ## 01:42
   8
   9 For the sample input, I now have:
  10
  11         DEBUG -- B=<0,3> H=        10
  12         DEBUG -- B=<1,3> H=        11
  13         DEBUG -- B=<2,3> H=       100
  14         DEBUG -- B=<3,3> H=       101
  15         DEBUG -- B=<4,3> H=       110
  16         DEBUG -- B=<5,2> H=         0
  17         DEBUG -- B=<6,4> H=      1110
  18         DEBUG -- B=<7,4> H=      1111
  19
  20 Which appears to be correct. I just need to figure out how this stuff is used
  21 now that it is correct.
  22
  23 ## 01:46
  24
  25 Also figured out how I can have a huffman tree just be based on an array of
  26 sorts that kind of builds up as entries are added. I can probably use that
  27 instead because it would be much smaller, although it does not have to be
  28 limited to specific data types. Instead of having nodes for every part of the
  29 tree I can instead just have an array of index references. Each index is in a
  30 pair always, so the array is a power of two. If the uppermost bit is set then
  31 a value is used, otherwise then a pointer is used instead. So basically it
  32 would be in a linear jump fashion so to speak.
  33
  34 ## 03:19
  35
  36 Using the new huffman code, need to figure out a way to find the associated
  37 symbol and the bitmask, if applicable.
  38
  39 ## 03:28
  40
  41 Appears a thunderstorm is approaching.p
  42
  43 ## 03:36
  44
  45 Appears my huffman tree is rather lopsided.
  46
  47 ## 04:13
  48
  49 And my traverser is not correct, it stops a bit short of a value so instead I
  50 have it stop on an actual value.
  51
  52 ## 05:09
  53
  54 Seems my file server disk is failing, it only boots and loads the OS when it is
  55 on its side, but it does it rather slowly. Either that or it is a loose cable
  56 or the SATA port is not working correctly. If it is the SATA port then Intel
  57 makes rather horrible ports if they die so often.
  58
  59 ## 05:21
  60
  61 I can access my data just fine when using another system and the same cable,
  62 so I suppose that the SATA ports are flaky and not working correctly, this
  63 means I will have to replace the board and such. I may be able to find a
  64 replacement, hopefully.
  65
  66 ## 05:33
  67
  68 Well, I suppose that board lasted about 5 years. I could though use a PCI
  69 SATA adapter but that might not be worth it, I will just find another system
  70 to use instead. This will be done after I sleep and wake up, since I have been
  71 up all night programming since I could not sleep. However I did get a bunch
  72 of huffman work going on, which is good. A slight break from the interpreter
  73 compiler part.
  74
  75 ## 10:12
  76
  77 Reading of the distance codes and literal codes are combined, so I should
  78 handle that case.
  79
  80 ## 10:43
  81
  82 Suppose to solve the huffman data, I just needed to read the top of the RFC
  83 document and just make the stuff there.
  84
  85 ## 10:59
  86
  87 My fixed huffman parser seems wrong. I read bits for the distance and the
  88 length yet it works.
  89
  90 ## 11:15
  91
  92 Yes it was swapped. Also I kept missing that the literals was combined with
  93 the length, so the same tree is used so to speak.
  94
  95 ## 11:20
  96
  97 Actually my length and distance methods were entirely swapped, the length
  98 method was handling distances and the distance one was handling lengths.
  99
 100 ## 11:38
 101
 102 I believe my sliding window has an off by one where the distance code which
 103 was off by one worked, but now that it has been corrected it is incorrect.
 104
 105 ## 13:32
 106
 107 Got spare computer in the mail today. Oddly it has a UK keyboard layout I
 108 believe anyway. It has the Euro and the british pound sign. However It has a
 109 plus over minus key which also has that double S section symbol. It was not
 110 working properly, however I just needed new RAM for it. It has a few dents in
 111 it but with the aluminum case I can sort of bend it back into shape, I just
 112 need to replace the LCD frame though since it has a dent in it. But anyway,
 113 I must fix the sldiing window offset off by one now.
 114
 115 ## 13:41
 116
 117 However, it seems I cannot install Mac OS X on it, so I suppose I would instead
 118 just go pure Linux instead if I cannot get it installed at all.
 119
 120 ## 14:39
 121
 122 Ok so the distance can exceed the end of the sliding window (just not the
 123 start). Looks like for any extra bytes it just repeats the sequence. Thus I
 124 will have to handle that specially as a kind of overlap thing.
 125
 126 ## 13:55
 127
 128 Ok so it now appears to work, however the input and output class file are not
 129 matched properly. My current inflater has a single extra byte of output. There
 130 are also a bunch of shifted areas too. The input has a sequence containing
 131 `0100046d61696` but mine is instead `0100036d61696e` at least for that
 132 portion. The debug sequence is this
 133
 134         DEBUG -- c 103 g
 135         DEBUG -- W 67 g
 136         DEBUG -- Read DC 59
 137         DEBUG -- c 59 ;
 138         DEBUG -- W 3b ;
 139         DEBUG -- in 60
 140         DEBUG -- in d2
 141         DEBUG -- Read DC 257
 142         DEBUG -- c 257 ?
 143         DEBUG -- Lent Code 257 > 3
 144         DEBUG -- Length 3
 145         DEBUG -- Dist Code 10 > 43
 146         DEBUG -- Distance 43
 147         DEBUG -- W 01 ^A
 148         DEBUG -- W 00 ^@
 149         DEBUG -- W 03 ^C       ---- Should be 4
 150         DEBUG -- Read DC 109
 151         DEBUG -- c 109 m
 152         DEBUG -- W 6d m
 153         DEBUG -- in 78
 154         DEBUG -- in 7f
 155         DEBUG -- Read DC 97
 156         DEBUG -- c 97 a
 157         DEBUG -- W 61 a
 158         DEBUG -- Read DC 105
 159         DEBUG -- c 105 i
 160         DEBUG -- W 69 i
 161         DEBUG -- Read DC 110
 162         DEBUG -- c 110 n
 163         DEBUG -- W 6e n
 164         DEBUG -- in f1
 165         DEBUG -- in 96
 166         DEBUG -- Read DC 1
 167         DEBUG -- c 1 ^A
 168         DEBUG -- W 01 ^A
 169
 170 ## 14:00
 171
 172 Unrelated but rather freaky is that when the screen is off on this used
 173 laptop I can see the Apple logo shining through the LCD. It is dim however so
 174 I suppose the Sun is bright enough even in cloudy weather to cause this event.
 175
 176 ## 14:05
 177
 178 Actually, getting the smaller of length and distance to use as the distance
 179 back is not correct. I need to check if it exceeds the bounds, then cap to the
 180 distance if it is larger.
 181
 182 ## 14:09
 183
 184 Actually the corruption happens much earlier than I expect.
 185
 186         DEBUG -- W 00 ^@
 187         DEBUG -- W 09
 188         DEBUG -- W 00 ^@
 189         DEBUG -- in 39
 190         DEBUG -- in 8f
 191         DEBUG -- Read DC 39
 192         DEBUG -- c 39 '
 193         DEBUG -- W 27 '
 194         DEBUG -- Read DC 258
 195         DEBUG -- c 258 ?
 196         DEBUG -- Lent Code 258 > 4
 197         DEBUG -- Length 4
 198         DEBUG -- Dist Code 8 > 21
 199         DEBUG -- Distance 21
 200         DEBUG -- W 08     ----- should be 0a
 201         DEBUG -- W 00 ^@
 202         DEBUG -- W 23 #
 203         DEBUG -- W 0a
 204
 205 ## 14:12
 206
 207 My code sequence is as follows, which is correct:
 208
 209         a0002002208
 210
 211 However it appears looking back that 08 is read instead of 0a, so it is
 212 possible that my sliding window is reading from the wrong end.
 213
 214 ## 15:18
 215
 216 This:
 217
 218         DEBUG -- BACKFRAG dx=7 sz=4 bf=1 ln=2 lbfs=3
 219         DEBUG -- src=0 rat=0 (0/6)
 220         DEBUG -- BACKFRAG dx=6 sz=4 bf=1 ln=2 lbfs=2
 221         DEBUG -- src=0 rat=1 (1/6)
 222         DEBUG -- BACKFRAG dx=5 sz=4 bf=1 ln=2 lbfs=1
 223         DEBUG -- src=0 rat=2 (2/6)
 224         DEBUG -- BACKFRAG dx=4 sz=4 bf=1 ln=2 lbfs=0
 225         DEBUG -- src=0 rat=3 (3/6)
 226         DEBUG -- BACKFRAG dx=3 sz=4 bf=0 ln=2 lbfs=3
 227         DEBUG -- src=1 rat=0 (4/6)
 228         DEBUG -- BACKFRAG dx=2 sz=4 bf=0 ln=2 lbfs=2
 229         DEBUG -- src=1 rat=1 (5/6)
 230
 231 Tells me that entries are being read I believe in the reverse order. The output
 232 index 0 should be the oldest of the distance and not the first.
 233
 234 ## 16:12
 235
 236 This looks wrong:
 237
 238         DEBUG -- hlit/dist 290: 6
 239
 240 Actually it is part of the distance codes, they are combined together as one.
 241
 242 ## 16:44
 243
 244 Well, reading the values correctly leads to the uncompressed class file being
 245 the same length while the one sent through my version of the algorithm ended
 246 up with an extra byte or so.
 247
 248 ## 16:46
 249
 250 Now I believe the sliding window is not working correctly, since I see many
 251 `cafebabe` and similar to that in the output stream.
 252
 253 ## 19:09
 254
 255 Well I made a bunch of decompressor progress, however I appear to be stuck on
 256 the sliding window part. I made lots of progress on the code since I last
 257 touched it however and it is mostly complete except for this last remaining
 258 issue. So I shall put it on hold to clear my mind of it.
 259