DISCLAIMER: These notes are from the defunct k8 project which precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26! The k8 project was effectively a Java SE 8 operating system and as such all of the notes are in the context of that scope. That project is no longer my goal as SquirrelJME is the spiritual successor to it.
Project's birthday today, but I am feeling a bit tired still from all the stuff I did yesterday. So might not be able to work on this today at all. I can run gitstats on this though so see how it looks after a year. That will take awhile, to convert and then run the program on it. In the mean time I can write down some notes. After a year I still do not have a bootable OS, however I have a partial compilation system and such. If I did not do any major cleaning I would probably have been generating machine code by now. So the stat generation will take a bit. The one major thing I like in recent times is the fixing of the code and moving it around to be more modular and cleaner. Although I thought I would be rewriting the bulk of NARF I ended up not really doing it, just patching out the bad things. I got rid of vmjrt which I really disliked. The new way of doing things is much better. In reality I have the k8.pro files. Kind of think of it, the only reason I had them was so I can tell which parts of the runtime in vmjrt are under each profile. However the completion stuff counts of the files to exist and contain valid JSON. I could really just infer the package level based on the contents of the run-time and such. So if it is java-library-3 then the class count is known and such.
Stat generation completed. Like I have noticed before my activity per week rises and then dips. The last moving of vmjrt to vmjar stuff has considerably cause a large spike in commits. I believe the hour of day totals completely shows my sporadic sleep cyckle. But those automatic commits really increase the totals so that information is a bit lost. However in retrospect it does not matter much as it is activity. Splitting up between 200 commits is much better than doing it in one giant commit since it is in smaller portions so it is easier to update and patch. I did not make much commits during December and the upcoming month of May. May was the start of the project but December was a slow time. So far my commit total is 37% for 2015 compared to 63% for 2014. 2014 had more months so far but for the most part has only 7 months of work. 2015 should bring more commits. If I were to make the same amount of commits as so far this year and as last year, then I should land on about 4400 commits during 2015. Doing the vmjrt moving as completely increase the total number of lines since the moves are considered single files. It would have been better (but slower) if it were done on unique files based on their sums. My mass commits do cause large spikes in the data. With my total commits and their massive jumps, I commit less than the linear average. Removing mass commits and drawing a linear line from start to the end. I exceeds my average commit level line for 5 months. Then about 3 months of below average (start of 2015). March to April was above. April to present is below. So not too bad.
I can remove the k8.pro files which are not in the library sources though.
I believe for SQ instead of doing stuff like BAMs, I will use floating point values as that can simplify things albiet it will be slightly slower on systems without an FPU. Since this is a game and ulps will matter, StrictMath must be used. I would probably also split it to have an engine and a front end which plays the game along with separated game data. The existing data that is stored in the enumeration of unit information could just instead be placed into JSON files instead. That way it will be easier to make mods which use different information on units for example.
My register moving stuff is incorrect, I need to actually move the registers to local positions rather than just on long/double but to do that I only need to change very little.
Just yanking in the old code with all of the global changes would just be very ugly so I am going to go through it and rework most of it so it is more easily handled and not as messy.
Although I wanted to avoid rewriting the bulk of the Java decompilation code, the technical debt would have haunted me because I knew it was very bad.
Although the run-time and class format can handle private interface methods which are not static, the compiler fails on them. Java 9 will enable such things.
The difference between this time and last time I had signature is that this time there is differentiation between the differing signature types. Before I had some random guess what it is which was horrible, now it is either just class, field, or method signatures.
Oops, I named my class signature "Class", that will cause some trouble. I suppose Type will work instead. Well that will not since there are type arguments and such. Maybe just ClassType will work.