08:52
I think it would be good if the deflate decompressor were moved to the IO project that I have instead of just sitting in the ZIP code so it could be used in more places because it is versatile. That way stuff like the PNG decoder does not need to bring in the code for reading ZIPs.
11:20
Actually one issue with data which wraps input streams like for ZIP files and
such is having a constructor which can throw IOException. This basically
means that stuff like new Wrapped(new Foo()) means if Wrapped throws the
exception then the wrapped Foo will never be closed. This definitely needs
fixing and I do need to refactor the ZIP code for this.
11:56
Okay, so this is my base64 decoded data:
Got: 86 15 6c c6 bc 60 76 fd 72 c6 90 61 a0 00 00 |..l..`v.r..a...|
Wnt: 48 65 6c 6c 6f 20 77 6f 72 6c 64 21 0a |Hello world!.|
So some bit sequences are correct but they seem to be in the wrong order so maybe the bit values are swapped perhaps? It would be as simple as reversing the alphabet to swap all the bits.
12:05
So now I reversed the bits and I get:
Got: 86 15 6c c6 bc 60 76 fd 72 c6 90 61 a0 00 00 |..l..`v.r..a...|
Old: 86 15 6c c6 bc 60 76 fd 72 c6 90 61 a0 00 00 |..l..`v.r..a...|
So reversing the alphabet had no effect? It should have an effect.
12:07
Actually that is because after swapping everything I swapped it again because I stopped at the array end rather than the middle.
12:08
Now I get this:
Got: 79 ea 93 39 43 9f 89 02 8d 39 6f 9e 5f 0f 0f |y..9C....9o._..|
Old: 86 15 6c c6 bc 60 76 fd 72 c6 90 61 a0 00 00 |..l..`v.r..a...|
Wnt: 48 65 6c 6c 6f 20 77 6f 72 6c 64 21 0a |Hello world!.|
And that is completely off, so that is wrong.
12:10
Maybe the bits are stacked on top, like... well my code does that already.
12:12
Okay, so maybe it is treated as groups of 24-bits and not 8-bits.
12:14
I should look at the actual algorithm so I can understand it better.
12:21
Moving the decoder around gets me:
Got: 86 15 6c c6 bc 60 76 fd 72 c6 90 61 a0 00 |..l..`v.r..a..|
Old: 86 15 6c c6 bc 60 76 fd 72 c6 90 61 a0 00 00 |..l..`v.r..a...|
So not that bad.
12:28
Okay adding a drain worked, just need to make sure padding works.
17:29
I need a test framework which is not messy. Something that is easy to define and is not difficult for adding new tests. Some form of limited reflection for methods would be nice especially for test methods. It would need to run in the environment also.
17:32
Actually it could be a simple reflection which take a single set of input
arguments or no arguments. But likely just Object[] would be the best thing
to do because that would make a variable number of objects without needing to
do complex things in native code for the call to work. It could also return an
Object too. But I am not completely sure though. But actually what could be
done for testing is instead having a thread local test storing thing then run
a test in a thread. I think that would be a nice means of doing things. The
only thing though would be that there would only be a single method of doing
things for the most part. Although lambdas could be simulated with
constructing with a bunch of classes. So basically there are test groups and
then there are sub-tests which can operate on objects or specific input. I
think that could work.
17:57
I have an idea, instead of putting tests in the build system, but them in their own timespace. That would be the test timespace.
22:27
Well, the thing is, I believe I need a better testing system which can test the code and such.
22:30
It would be nice though to include tests in the source code for files. I can have extra classes at the end of classes and I could perhaps throw tests there. Then during the compilation stage I can just ignore them for the most part.
22:35
But, it could be part of the source code itself, but in a different file. Basically just specially prefixed source code files. But the compiler normally does not handle files which end in a different extension. The baseline build system could just ignore these test sources. Then I can have some test framework stuff in the base CLDC. The build system could extract and not include the tests, but then make a JAR which includes the tests which could be ran at run-time (or at least compiled into the binary).
22:41
At least with the tests included with the source code, it could be easier to include them and to make sure everything is tested for the most part.
22:45
Well, this could be an idea. Instead of having a test timespace, well instead
of having a bunch of test projects I can have a modified source project
system which has a layering system which would allow tests to be inlined
similar to how Maven does things. So basically there would be
cldc-compact.test as a directory next to cldc-compact rather than having
a test/mids/test-cldc-compact. Then I can have a script which just is able
to run those tests or generate a JAR. Instead of a manifest there would just
be an implied one automatically generated from an input source project. But
to the build system itself when it comes to binaries these test projects.
I really would only need to modify SourceManager and Source accordingly
but it could be done like that simply. These projects could exist. I would
get all the test projects accordingly. Also the source project for tests
can automatically generate some special files that can take care of it.
23:09
I believe in the long run this will provide a better result and be easier to maintain. Also the way I wrote the compiler it would not really care where the files came from.