assets/developer-notes/stephanie-gawroriski/2016/09/21.mkd

   1 # 2016/09/21
   2
   3 ## 06:30
   4
   5 Today is the last day of summer.
   6
   7 ## 06:58
   8
   9 The resource accessor will need a specific means of obtaining a set of
  10 resources under a given name and returning a kind of reference to them. This
  11 would be used so that `ServiceLoader` operates correctly in launched programs.
  12
  13 ## 10:44
  14
  15 This means the build system refactor has been completed. I just need to test
  16 it on Windows.
  17
  18 ## 12:27
  19
  20 I am considering moving all of my developer notes to outside of the repository
  21 and into unversioned space. However, I would need an efficient means of editing
  22 them. For the most part, any notes that I do write remain the same and sort
  23 of bloat the repository. It would considerably cut down the number of revisions
  24 where I just type notes.
  25
  26 ## 12:39
  27
  28 I would need to rewrite some of the blog scripts however. Although it should
  29 make things a bit easier and remove a project containing notes.
  30
  31 ## 13:42
  32
  33 So now I moved my note system into the unversion space, and I am using nano
  34 right now to write them as needed. I suppose that would be much better when
  35 it comes to the future size of my repository and checkout since the notes
  36 take up quite a considerable amount of space.
  37
  38 ## 13:46
  39
  40 Of course I have to wait a day to see if my script works the same still.
  41
  42 ## 14:03
  43
  44 I am very much contemplating shunning all of the old blog files along
  45 with any commits which only contain note based changes. That would
  46 considerably cut the number of commits performed. To do this, I can
  47 download the manifests for every revision and extract the information
  48 to get the SHA-1 sums of the files to shun, the notes related stuff.
  49 But for a just in case, I suppose only if their size is at least 13
  50 bytes or perhaps even 12. This would be for the header and the hope
  51 would be that the SHA-1 is unique enough with these few bytes so
  52 that nothing else gets accidently shunned. What I can do is use the
  53 timeline command as:
  54 `fossil timeline -n 0 -p src/developer-notes/ -t ci -v -W 0`. Then
  55 I can read on DELETED, REMOVED
  56
  57 ## 14:14
  58
  59 Although that would be a bit ugly. I can easily shun just the note
  60 files easily however. There is the fossil purge command however.
  61
  62 ## 14:28
  63
  64 Well, shunning can completely break my repository especially since
  65 many of the changes were made long ago. So it would be best if I did
  66 not do such a thing. I could probably recreate the repository and
  67 rehost it, but that would be much work especially when it comes to
  68 tickets and such.
  69
  70 ## 15:56
  71
  72 Not much programming today though, so I suppose that I can work on
  73 the JavaDoc generator potentially or continue on with the JIT.
  74
  75 ## 18:12
  76
  77 I do have to get used to the new note system to prevent cases where I
  78 accidently remove notes and such. However, allocation of registers is
  79 seemingly rather simple.
  80
  81 ## 18:19
  82
  83 Something that could be handy would be indirect dependencies, but that could
  84 get confusing to implement. Basically, if I change a base project it does not
  85 mean that all projects that depend on it have to be rebuilt. That could lead
  86 to strange issues and potentially bugs however.
  87
  88 ## 18:42
  89
  90 One nice thing is that I can write notes out of band of actual code now,
  91 which is nice. I had always tried to keep any notes I have written if they
  92 were completely different in their own commits. One thing I need to actually
  93 work on is the launching system, I noticed a slight sluggish speed when it
  94 comes to launching. This is likely due to the single streamed ZIP opening and
  95 closing constantly, which requires the ZIP table to be parsed over and over
  96 again. However, what I can do is rewrite the ZIP code so that directory
  97 searches are not that costly. That is, the central directory entries are
  98 parsed as they are iterated. I could also potentially perform some caching
  99 of entries or resources.
 100
 101 ## 18:48
 102
 103 One thing to consider in my native code writer factories is that I do not pass
 104 a stream at all, so there is actually no way to write the actual bytes needed
 105 for output. So the factory will need to be given an output stream where there
 106 can be some common instruction building `OutputStream` variant that is more
 107 friendly to the architecture being written. Then this way there can just be a
 108 base class which architecture specific code wraps accordingly. So in effect,
 109 there would be a `MIPSOutputStream` for the most part which has special
 110 methods for writing all varieties of instructions.
 111
 112 ## 19:09
 113
 114 One thing to consider is that RISCs will be very similar when it comes to how
 115 they generate code. For example they do not have memory to memory operations
 116 for one. So in hindsight, there will be duplicated in the MIPS and PowerPC
 117 native code writer classes in some areas because they essentially will be
 118 doing the same exact thing.
 119
 120 ## 19:20
 121
 122 Looks like the builder may be using the wrong set of dependencies. For the
 123 MIPS project I am trying to build it fails because it cannot find RISCWriter,
 124 so as such I believe it is potentially using the binary project's dependencies
 125 rather than the sources.
 126
 127 ## 19:25
 128
 129 Also for the ZipFile code, when I refactor it. Due to the fact that I now have
 130 SortedTreeMap, I can lazily populate entry names for lookup. So say that for
 131 example an entry needs to be found. It will iterate through the contents of
 132 the ZIP and then it will fill the map accordingly. If the map already has the
 133 entry then that will be checked first and returned. If all entries have been
 134 read then there will be no linear search at all. So essentially this allows
 135 entries to be retrieved on an as-needed basis. One thing to consider is that
 136 this would increase the package manager speed because usually the manifest
 137 will be written first, so a request of the package information will be a
 138 `O(1)` operation. Also, if I can know the position of the start of the central
 139 directory then it would also be possible for the base positions to not be
 140 known until linear scan time. This way if a ZIP is opened and only the first
 141 few entries are used, it does not waste time calculating everything else.
 142
 143 ## 19:31
 144
 145 The ABI will need scratch registers for copy operations to be effective. This
 146 will definitely be needed by the RISC code writer for stack to stack
 147 operations.
 148
 149 ## 19:35
 150
 151 So I will definitely need to refactor the ZipFile code. However not working
 152 on the allocator much for some days has somewhat cleared my mind of it.