# 2016/03/12

## 00:03

I get it, I am only checking one side in grow, I need to handle more of it.

## 00:29

This time I get 'X' (88) instead of 'T'.

## 10:56

T is 0h54 or 0b1010100. And X is 0b10110000 or 0h58. So I am pretty much a bit off by a single bit being in the wrong location. These are huffman codes so what I want is 0b10000100. What is something though is that I get that desired value when it is being read.

## 11:02

So it appears my read value from readFirstInt is shifted too high it seems. Since I read 0b100 which is 4, but I instead return 8 from it.

## 11:08

Changing the read to MSB fixes the issue. Normally I should not need to do it such as that, so the int conversion is lost somewhere.

## 11:12

Actually I get it. I offer integers with LSB so they get added in that order, although when I get those integers they are read in the same order.

## 11:15

When placing the lowest values are pushed in...

``````0011001001111
^^^^^^^^  -- 0b11110010
``````

Then when reading the same order is used.

11 (0b1011) is added to become

``````11010000
``````

``````11010000 10010010
``````

``````11010000 10010010
F
TT
HHhhh hhh
``````

Reading first values results in 0b00100001, which is 33. However the lowest six bits get chopped off so it is instead read as: 0b0000100. This is 4.

## 11:25

Thinking about it: 0b0010000 from lowest order. This is 16.

## 11:31

Just going to go with reading it as MSB since it works.

## 12:47

Must create the sliding window code and put bytes in there, also need to figure out how the sliding window reading works also.

## 12:52

For reading the distance, I can use an algorithm for that. Each distance group appears in sets of 4 extra bits, the first 8 values have zero extra bits and represent single directories. So essentially instead of a lookup table I can use a linear sequence calculator to determine the distance to use. Then if there are any extra bits then they can be read.

## 13:02

This graphing calculator I have is very handy during programming.

## 13:19

And the distance and length handling was actually quite simple. What I need to do now is have the actual sliding window implemented.

## 14:09

The distance starts at the furthest byte back, because otherwise it would not make sense.

## 14:25

So now I have a working sliding window. I just need to figure out where an infinite loop occurs now, most likely at the end of the read.

## 14:39

Was actually caused by the stop value being treated as an output byte value. So now the inflation algorithm passes and the resulting bytes are given. Now I need longer sequences that do other things. One thing I will need is random unique bytes that have nothing in common.

## 14:46

Ok so I have a random data input which is completely terrible at compressing as it ends up being larger.

## 21:12

Was doing lots of outside work before, rather tired.

## 22:47

I believe the ZIP is reading data from the incorrect location.