SquirrelJME/SquirrelJME

# 2016/03/10

## 05:31

Up early.

## 06:34

Only about a month left for that Creator CI40 KickStarter, it will be pretty
nice to obtain those boards as I can do development on them.

## 08:21

I believe in my implementation of the JVM I am going to limit the maximum
number of loaded classes to 65,536. Basically classes would be referenced by
a two byte index. I could also reduce the class count and use the upper bits
for some special details potentially. I will probably need a flag to indicate
if something is a ROM class or a RAM class, so I suppose the upper bit would
work. So that means 32,768 built-in classes and 32,768 loadable classes. Since
Java ME only has a single class path, every built-in class will already be
loaded so to speak. That is the CLDC and everything else will be part of the
binary.

## 08:26

I am going to probably need JSR 177 for `MessageDigest` and such.

## 13:15

I believe I need a tester for the inflate algorithm with known input for
example, this way I know what to expect.

## 14:31

The internal `__escape` method in the test would probably be better if it did
not rely on `StringBuilder` as I am removing it right now. This way there is
no intermediary string to work with for example.

## 15:27

Never actually used huffman before. My literal representation check works to
make sure that the mask is always of the lowest mask value.

## 15:49

I can keep the huffman tree internally a secret so that in the future if I find
a better algorithm I can change to it without having to worry too much any code
uses it. Right now I suppose I will use objects and such and have a node
structure. The tree-like structure would be the easiest initially to implement
although it would use a bunch of memory.

## 17:16

I could store the tree in an actual array and just use `ArrayList` to simplify
implementation of it. The tree would always be some kind of multiple. It would
be treated as a binary tree with value nodes (`Integer`) or `null` if there is
no value at said position. So for a single bit there are two entries. However
if 2 bits there are four entries. So basically there is an entry for each
binary bit. Just the one thing that has to be done is that the tree has to be
recreated if a new depth is discovered.

## 17:20

I could actually use `Number` and have a special number. For example normal
values will appear as integers. There will be a special number which is of a
single instance which would be called a deferred value (which cannot have its
value taken) and is used to indicate that the end of the tree has not yet been
reached.

## 17:26

Actually it might be better to have a general purpose huffman tree which can
work with any kind of object. That would be the most effective.

## 17:32

The huffman tree could also extend `Map` and use `Integer` as its key, sort of.
However, in this case I would only support read-only access to the map because
putting in a key would not make sense because a bit length is required. Also,
the key might not even make sense because there would be upper regions of
zeroes that must be included also. Well, based on my own thinking, there will
always be unique tree nodes for each key, so that will work out. However the
iterator will not be able to give an exact path to use it when decoding. So
I would just make it iteration only so I could for example print the
representation of the tree using the basic map structure for example.

## 17:36

Also it probably does not make sense to have a `HuffmanTree` in *extra-io*, it
should probably instead be with the collections.

## 18:59

I could use an array, however say if I do not use all of the entries in it,
most would end up being wasted. Usually this is a problem with higher bit
counts. In general the huffman tree is rather lopsided. Using a bunch of nodes
would be simpler though and would increase the object count a bit though.

## 20:30

Looks like I was missing `isInstance()` in `Class`.

## 20:42

Thinking about it, I can just use a `HashMap` and use that instead of the
huffman tree. A red-black tree would also suffice too. Actually no, due to the
variable size nature of the bits.

## 20:59

So the first letter I decoded in the test that I found on the internet gives
me my first letter, which is 'T'. I need a bit queue which can fill an internal
queue when enough bits were put in.

## 21:56

Most likely for the fixed huffman table, I do not need to calculate the table
at all because I can use if statements and such to determine what the actual
value is. It would be very similar to UTF-8 handling. That would save on
speed because most of the values are very linear.

## 22:36

I am getting there:

    54657374696e6754657374696e67
    0054657374696e005404

Need to get read of that leading zero.

## 22:43

Actually my distances are miscalculated, I am treating values above 256 as
values to be added to the output when that should not be the case.

## 23:34

Even getting 84 in there is complex. Using the mask will not work because the
values are off so to speak.

## 23:39

The problem is that the 144-255 variant has all of the bits set which makes
masking troublesome because in all situations it is always true.

## 23:41

I would guess that I would use addition or subtraction on my input and figure
it out that way.

## 23:57

I just have to go through the process of elimitation. I already elimited D for
the initial value, I just need to eliminate the other 3.