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.
Suppose a short break is in order, still have yet to reorganize my room however.
Decided to write the dependency walker to use a tree for traversal and such, makes things a bit simpler.
Currently my dependency walker code does not use recursion at all.
So the big test of my new dependency walker would be to see if the current package building stuff reaches the current state on a clean slate so to speak.
Compiling an empty set on my atom system gives me
So even though this is a complete from scratch build it seems slightly faster. I am about to see the results on my PowerPC laptop however. Since it is a clean build and the interpreter is used it takes a bit longer. The resulting real time is
So slightly faster it seems. Hard to tell however as there are no true benchmarks being done.
I do however have to rework the PackageBuilder eventually to make it not a complete mess and use the new DependencyWalker code when finding packages to build. The PackageBuilder is nearly 1700 lines of code and a bunch of merged classes together. Most of the code is from 2015/05/25, and seeing that it is about 6 months later I write much better code now.
Had a dream that I switched to Java 9 (since it was released). However if Java 9 does come out, I may just translate my code to it and such provided I can build it and it is available in OpenJDK. In my dream though Java 9 changed a bunch of stuff.
They added unsigned types and new constants for 128-bit, 256-bit, and 512-bit integers while removing the normal constants since the first version, was a nightmare.
Well the CI40 board has been funded, now it just has to remain funded.
I can probably remove the ".times" file and instead use the time given inside of the ZIP file. The ZipEntry API since 1.8 supports getting the modification time of a ZIP which is handy. This can be used by hairball to detect itself being changed (so it recompiles self for example), very meta.
Actually, I could devise a system where I can incrementally build if source code is available and the binary package exists. It will result in slightly slower checking if packages are already rebuilt but it may produce faster recompiles. So basically if a JAR exists it can source from few locations in that JAR rather than doing completely clean rebuilds. This would be handy for large projects such as the class library. However the more classes that exist the slower the checking of dependencies is because class files must be loaded. However most of my changes are rather small so in the end it may prove a bit faster for very large projects with few changes. I suppose for speed I should only consider dependencies in the self package level rather than projects the project being built depends on. However for that, there could just be an incremental build database but that would add complexity. So I suppose if a dependency gets updated there will be a forced normal build similar to how it is now, but if all dependencies are untouched then incremental mode will be attempted.
Well, I can do it for all dependencies but I would need a incremental database to be built alongside the JAR so that the incremental data does not infect the JAR file with data that is only used during build.
Using all 2K of the space, the Arduino Uno can emulate a MMIX system with 256 64-bit registers. The system specific registers would lose out however and there might not be enough free memory for having an attached SD card for example to be the main memory along with filesystem. However due to the memory limitation, emulating a MIPS64 system would probably be better.
So as before, I am deciding to not have a incremental mode because that would add complexity although it could actually work out.