assets/developer-notes/stephanie-gawroriski/2016/10/11.mkd

   1 # 2016/10/11
   2
   3 ## 09:34
   4
   5 I believe I will move the configuration bit stuff out of the method and into
   6 the constants.
   7
   8 ## 10:11
   9
  10 Documenting the configuration choices took much work, however by doing so I
  11 have learned a tiny fraction of OpenGL ES and can decide how I want to
  12 continue.
  13
  14 ## 10:41
  15
  16 I could get my own enumeration set and extensions, but I am not too sure I
  17 would even need such things. However the glGetString for versions and such
  18 will be unique.
  19
  20 ## 12:06
  21
  22 Thinking about it, I should definitely actually implement an interpreter
  23 before writing the JIT which I cannot seem to find the will to work on. With
  24 an interpreter, everything would then be implemented for the most part. I can
  25 just keep it very much straight through Java.
  26
  27 ## 12:41
  28
  29 The markdown writer for everything should be split off, otherwise I will have
  30 gigantic methods for writing the stuff.
  31
  32 ## 12:42
  33
  34 I also need basically a type representation because essentially super classes
  35 and interfaces can be generic for the most part.
  36
  37 ## 13:11
  38
  39 Actually for the interpreter, I can make it `auto-interpreter`. It can be
  40 linked into the project system and automatically compile projects as they
  41 are launched. Since I have the base for LCDUI I can setup interfaces in a way
  42 where their requests are forwarded to some kind of out-of-interpreter
  43 interface. The interpreter would then be able to run on SquirrelJME itself. I
  44 can use it as a test environment also. It could also be used to test things
  45 such as Squirrel Scavenger and perhaps other JARs that may exist somewhere (or
  46 be converted into projects).
  47
  48 ## 14:17
  49
  50 Definitely I will switch the backend display stuff to use engines or similar
  51 instead of using service loaded stuff. The main "kernel" program will actually
  52 use a hardware display backend, but every program that runs will just use a
  53 virtualized one. The virtual one would be one that forwards.
  54
  55 ## 15:11
  56
  57 I have made the JAR namespaces agnostic so that other ones could be
  58 dynamically loaded at the start or at run-time potentially.
  59
  60 ## 15:40
  61
  62 One thing to consider is that I can have duplicated code essentially between
  63 the interpreter and the launcher. Effectively, the bootstrap to start the
  64 launcher only once. So the question is, should optional dependencies be loaded
  65 regardless in all cases?
  66
  67 ## 15:47
  68
  69 Also, the media code I grabbed from MIDP and the MEEP media code will conflict
  70 each other since they share the same package and classes.
  71
  72 ## 15:51
  73
  74 I suppose the initial bootstrap can just use the _Class-Path_ setting and just
  75 strip the JARs to get namespace names that are available. If a dependency is
  76 missing from that, it is just ignored. This is then used to build the class
  77 path as required.
  78
  79 ## 15:53
  80
  81 Although, I could actually use a kind of _X-SquirrelJME-UserMode_ option.
  82 Basically, I would just essentially only use _X-SquirrelJME-Depends_ in the
  83 initial bootstrap mode (ignores optionals) and the user mode settings would
  84 be optional ones. The launcher is not going to need LCDUIs that implement
  85 framebuffers or native widgets at all (those calls would be forwarded up
  86 pretty much). So basically, **midp-lcdui** would have optional depends to
  87 everything, but it would have a UserMode dependency on the LCDUI for
  88 usermode. Then I suppose what is needed are external mode dependencies. The
  89 external mode dependencies would be used by the build-system to calculate
  90 dependencies.
  91
  92 ## 15:58
  93
  94 So in short, the dependency types:
  95
  96  * Required -- Required regardless, outputs to MIDlet/LIBlet and Class-Path.
  97  * Internal -- Required dependencies, outputs to MIDlet/LIBlet
  98  * Optional -- Optional dependencies, outputs to MIDlet/LIBlet and Class-Path.
  99  * External -- Optional dependencies, outputs to Class-Class only.
 100
 101 I also need to implement standards so to speak and configuration providers so
 102 that my generated JARs to not depend on cldc-compact but rather say CLDC-8.
 103
 104 ## 16:11
 105
 106 Looks like my version of `cal` outputs `5f 08` to underline previous
 107 characters, which I have never seen before.
 108
 109 ## 16:24
 110
 111 So I then need to determine how building will handle such things. I can no
 112 longer user a simple boolean value for optionals. This also changes the
 113 recursive lookup mechanism also. So I suppose for optional lookup there is
 114 NONE, INTERNAL, and EXTERNAL.
 115
 116 ## 17:40
 117
 118 I believe what I am going to do is remove the single export system if the
 119 interpreter pops up and is fully working. Perhaps though. Although I can
 120 remove the virtual engine stuff because the interpreter would replace
 121 such things.
 122
 123 ## 18:16
 124
 125 So now I do wonder if I should just simplify the LUI/LCDUI system. Potentially
 126 remove terminal, framebuffer, and just have something right on top. The one
 127 that would be internal would be a system forwarded one that perhaps uses
 128 IMC to communicate with the kernel or the launcher. The only issue with using
 129 IMC for this would be that everything would be slow, including games, due to
 130 the overhead of the communication socket. Basically the client for the LUI and
 131 LCDUI system would use a buffer of sorts. Although, it could be a kind of
 132 mixed setup. I would need a cross-VM array for data passing, or at least a
 133 window to an array that exists in a global memory spot.
 134
 135 ## 18:22
 136
 137 I would definitely need to encapsulate the buffer used by clients. Well,
 138 passing raw data could actually be done so to speak. I can essentially have
 139 LUI/LCDUI be a client implementation always. There would just be an
 140 implementation specific connection to the outside world. The client would
 141 essentially have the ability to request resources such as byte/short/int
 142 arrays for graphical buffers. Then another thing I must handle would be cases
 143 where there is a native widget system that can be used. However, I cannot have
 144 a single server that shares multiple instances at once because that can get
 145 really dodgy and they could cross talk perhaps. So that means that I will
 146 need a class that is perhaps called `ServerConnection`. The client would
 147 create instances of that class. Launched programs will use the class
 148 `ClientServerConnection` which uses some magical RPC to access the kernel.
 149 Each connection would be a single display so to speak. The client would just
 150 forward to the server via IMC or similar.
 151
 152 ## 19:36
 153
 154 I am going to go with a kernel socket interface, package private in
 155 SquirrelJME, but with a class that manages the sockets and such. I will have
 156 it where socket data is sent as any type of array, except Object, so that
 157 mutliple types of data can be used. There would also be a packet descriptor
 158 also.
 159
 160 ## 19:55
 161
 162 So I can easily do that, however I suppose the kernel socket class should be
 163 abstract and have it where there is a static connection open. There would
 164 also be a protected constructor. When SquirrelJME is not running the
 165 LCDUI/LUI code can detect this and spawn some kind of handler of sorts. But
 166 the UI code would essentially rely on the built-in classes. However, this
 167 means the build system has to include cldc-compact and cldc-full in the JAR
 168 otherwise it will never include the socket and reserved code at all.
 169
 170 ## 20:31
 171
 172 So actually, I will need a feature that I have talked about for awhile, and
 173 that would be co-dependencies. I can have the SquirrelJME CLDC stuff, that
 174 is anything that is used internall in another project. Then using a
 175 co-dependency I can have it where it will be included in the source path
 176 and included as if it were part of the source code. I suppose it would be
 177 co-source of sorts.
 178
 179 ## 22:49
 180
 181 So now the socket code will not be an issue at all for the most part, I will
 182 just have to implement it in a correct manner. I would suppose that it would
 183 be threaded in operation with synchronization locks. So this means that the
 184 display interface will create the server in a thread. However, the client
 185 connection would not use a thread at all. I just need to think of a socket
 186 interface now.
 187
 188 ## 22:51
 189
 190 And this means for simplicity that the BUI code goes away now, and I suppose
 191 the terminal code also. Everything will just be a display socket connection
 192 for the most part along with servers.