00:02
So I suppose I did much stuff, wrote image downscale, dowscaled images and such. Did some interpreter stuff, but setup an interface for the launcher. The kernel and such at least for the JVM wrapper for now could just use the interpreter which I have been writing. I must modify the interpreter slightly so that it can garbage collect a bit easier. However, now that I have the actual kernel stuff in place I can handle system calls and magical calls. This means that I can write for the intended environment without needing to have some kind of odd bridge. So the first kernel of course would be the one that runs on an existing JVM. I can then go deeper and then port the kernel to SquirrelJME and interpret on the interpreter using the line based console interface in MEEP.
07:22
Hopefully today I can get a bunch of commits done similar to yesterday. Although looking at the graph, most of my commits are on Saturday and Sunday.
08;43
I will need to develop a library which can consume events generated by the kernel and then provides those interfaces to say perhaps a game. Some systems such as the Dreamcast support multiple keyboard and mice connected to a system. So a game for example could use that kind of support. Joysticks could also be supported. However there is a bunch of code that varies between operating systems and the level of support.
08:58
For final fields with known constants, the fields could just not exist or
be allocated at all. Their value never changes and it can be represented in
the byte code so to speak. However for the dynamic compiler their values
still need to be known and assigned to a specific field.
09:46
Some of these keys seem absurd, but you never know!
09:58
Actually for some variable controls, I could just have a variable control group instead of having tons of on/off buttons.
10:27
Actually, I should move the event handler stuff and remove the special buttons.
10:58
Depending on how some input is done, I can have synthetic keys so to speak. So for example if
13:11
For the class lookup, I hope I am using References when it comes to class caches.
15:05
Actually, there are optional liblets. This means I need to adjust my build system and have optional dependencies. On the host build system, the dependencies would be forced however as if they were hard dependencies. However on the target system they would become optional. This can be used for example to lighten the cross-compilation system so that not every part of it has to be included.
15:15
Then this means, much lighter now.
16:04
Looking at the AWT key codes (which I am basing KeyChars slightly off) there
is SEPARATER.
17:28
In my event stuff, I completely forgot some bytes in the 32-bit integer. So I really have plenty of room for codes and such.
19:17
I suppose I did not get much done today at all.
20:04
The kernel interface will have to duplicate the FileSystem class and such
without requiring that nio be included. However, I could just force the
inclusion of NIO for filesystem support. NIO could be optional if it exists,
however having bridges would complicate things a bit. Also duplicating the
entire FileSystem interface would also be a bit complicated. However the kernel
FileSystem would have to be abstract. The FileSystem for the CLDC lacks
some things which are missing on host JVM and such. However abstract classes
should not trigger it. However the Java SE would need to have do not calls
or duds when it comes to the other methods.
21:07
Actually I can do something like this, as long as another idea is also used.
Basically I need an executable finder or similar that can provide executables.
There would be two basic executable finder kinds. Internal ones which use
precompiled binaries that are part of the ROM for example. Then another one
which uses a filesystem. When it comes to the filesystem, the kernel will have
an Object which is an internal representation of a kernel friendly filesystem
which is declared in another package. The console interface would use the
executable finder to show which things are available (the midlets that can
be executed). The internal NIO code would then just grab the filesystem that
is provided by the kernel.
21:20
Then this way for certain setups, there does not have to actually be an actual filesystem used. So on these such systems there does not need to be much of a worry about including FS support when it may be pointless or waste space.