A new month. Time for a code review.


So let us see then. At the start of the month I did a major removing refactor. I split apart the extra-util and such and made a bunch of sub-packages with just a few classes. This is helped out since in the future it would be easier to not use certain things and to keep it very modular.


I also optimized the code which the deflate decompression code uses, making it a bit faster. Also performed a refactor of the deflate code so that it is much better and easier to maintain.


Then I made squirreljme.error which is definitely a much better way to handle error codes. Later in the month I made the decision to use specific letters for error codes in a package rather than thought up ones. This is better because I will less likely write collisions with error codes. I also wrote some scripts which can scan the source code and output the used error codes so that I can easily find which error was thrown, its description, and the location of where it is declared.


I had performed a bit of the SSA-like program generation but I stopped that and removed the code later in the month.


I made my own unmodifiable collections handle RandomAccess for List which is important for binary searches being fast.


I also performed a move over and splitting of what is now the class interface code. I also implemented part of the byte code handler, I am going to keep that but it is going to get some changes due to the new way that the code operates. For example instead of having the byte code do the verification stuff, it just runs the classes though. One possible thing to have however is an optional verifier on top of the byte code input or one attached to it. Generally ClassPath could be used as a hint to the byte code. So I could perhaps have a verify(ClassPath) method for the byte code in a class. I can also consider that if I give a ClassPath to a get of an instruction that it could create a synthetic instruction based on the current ClassPath when returning an instruction. I will have to figure that one out though and have a clean and neat way to have rewrites without making the code a mess.


I wrote a bunch of UI Code but I ended up removing all of it because it just would not work. My current plan is to provide cm-based display interfaces so that the various details of displays are hidden away.


I wrote some of the kernel code, but the bulk of that has been changed to be much better and more manageable. Although incomplete I like the current version more than the old version.


Implemented support for reading XPM images which will be handy. I also support now optional dependencies for liblets so that specific projects do not have to exist. I need to adjust that however, where optional dependencies are not considered at compile time so that using them results in an error. Although to the compiler and the classic runtime they would be treated as hard dependencies.


I also got a mascot, which was drawn by puppenstein, it looks really nice. I then derived lower resolution icons from the mascot and also look nice. So the classically sized icons will fit for older and more lower resolution systems generally.


I interrned the strings in NCIUTF so that UTF strings are equal to each other when it comes to the JVM. They have to be interned anyway.


I also decided against a monolithic kernel and decided instead for a microkernel. The microkernel would be smaller, easier to implements, and more modular. Also the microkernel would work far better for the rerecording virtual machine because the system calls themselves can be used in the replay.


I then simplified the kernel and made it much better and it should not turn into a giant mess as it would have previously.


A bunch of days were spent on the UI code which was deleted, however that was an eductional experience. The new way which I plan to do the UI should be far better and less complicated to support.


I also added ClassPath along with ClassUnits which generally is a much better interface when it comes to locating classes. The ClassPath can also perform verification also. The beneift of ClassPath is that it is more directly used.


I also now have a basic kernel startup sequence, before all kernels would start up depending on the implementation. However that would have been messy and would require much duplicated code. So instead now the kernel launches the launcher, which will then handle the main arguments (-classpath and -jar).


Also decided on two interpreters: a standard one and a rerecording one. The standard one would be used for faster JVM based execution so I can write the main library on it. The rerecording one would be used for debugging and could be used for TAS. I have always been interested in TAS, so supporting that would be very nice.


And that was the month for the most part. Now onto the statistics via gitstats (with my repository converted to git). The past 4 weeks I have been getting much work done, this is likely due to waking up early and sleeping early. So generally a fixed sleep schedule is much nicer. I made 961 commits this month, so lots more work was performed. I was generally more active. My second most active month is March with 524 commits. Right now I have almost 2000 commits. My previous project which spanned 2 years has about 8500 commits or so. Looking at the file counts, they went up in the middle of the month but then went back down. I would say that this is refactoring and cleaning things up. The number of lines in the source code also went down.


So I would say that I got much work done.


Ok so, what I need to do is determine the best way to setup a process which would be given a thread and an entry point. I suppose createThread() should be given a process, with the method to invoke, and the arguments to that method in boxed form. That is the kernel can only use arguments which are of primitive types or String.


The method and arguments can be handled by the implementation specfic kernel.


So for the interpreter when it comes to processes, there would be a core that acts as a kind of memory space for execution. Threads would use this memory space for objects and such.


Actually the interpreter data stream will have to be structured. If it is not structured then it will be difficult to handle details. I would suppose to keep it simple there will be input and output arrays for commands. There will be a command code written along with the passed arguments types in some input array. Then when read a command the reverse could be done to reinitialize values and such. So I need a command data set which stores commands to write to the stream along with the type of command.


The data commands would work better if they could be closed and reused as needed. Then if they are not needed, they can be garbage collected.


This data packet code is much cleaner.