07:44
A new month. Time for a code review.
07:50
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.
07:51
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.
07:52
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.
07:55
I had performed a bit of the SSA-like program generation but I stopped that and removed the code later in the month.
07:56
I made my own unmodifiable collections handle RandomAccess for List which
is important for binary searches being fast.
07:57
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.
08:01
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.
08:02
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.
08:03
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.
08:05
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.
08:06
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.
08:07
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.
08:08
I then simplified the kernel and made it much better and it should not turn into a giant mess as it would have previously.
08:09
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.
08:10
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.
08:11
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).
08:12
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.
08:13
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.
08:20
So I would say that I got much work done.
10:41
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.
10:43
The method and arguments can be handled by the implementation specfic kernel.
11:13
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.
15:21
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.
19:56
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.
20:28
This data packet code is much cleaner.