Up early.


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.


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.


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


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


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.


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


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.


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.


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.


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.


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.


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


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.


Looks like I was missing isInstance() in Class.


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.


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.


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.


I am getting there:


Need to get read of that leading zero.


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.


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


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.


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


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.