07:41
What I need is an unbind
in ActiveBinding
but one where it has a cause.
For example it could be unbound because the value is being destroyed or the
type is changing (for example INT_TO_FLOAT
). This would be used by the
engine to determine if the registers should stay the same or if it should
just re-allocate new values.
07:43
Actually not unbind
, but changeBinding
.
08:53
I do wonder that __destroyStack
and __deAliasStack
can be moved into
the active binding slots and such. Also, I am going to need a global state in
the cache state. I would not need to pass multiple things around at all. So
the question is, does changing the active binding allocations and such cause
machine code to be generated? I would say for simplicity that it does not
because that way multiple active states can be juggled and such. I do however
say that the sub-JIT should do such things. De-aliasing can be done by
setType
and such. However, whenever something is aliased, the type that it
is the type of the alias.
11:34
I suppose I will need two copy operations. One that potentially aliases and one that does not, but where the active state is used. I would also need something perhaps for generating instructions also.
14:03
In the RFC 1951, MAX_BITS
on page 8 is capitalized. I calculate the value
each time. So this makes me wonder. And the code in ZLIB has the following:
deflate.h:48:#define MAX_BITS 15
.
14:45
So this is where the code fails to start decoding properly.
DEBUG -- 09 `eLength(code),??????distancetree.getValue(this.?`
at net.multiphasicapps.io.inflate.InflaterInputStream.
__decompressWindow(InflaterInputStream.java:598)
at net.multiphasicapps.io.inflate.InflaterInputStream.
__decompressDynamic(InflaterInputStream.java:398)
at net.multiphasicapps.io.inflate.InflaterInputStream.
__decompress(InflaterInputStream.java:329)
15:03
Actually looking at the code, it appears that the problem is with the distance
perhaps. I believe the written sequence in that group is \tint dhclen =
when
it should be __handleLength
which is 13 bytes. The assignment appears on
line 348. The appearing __handleLength
appears on line 375. So it is
possible the distance tree for one value is read incorrectly. However, the
incorrect file is 27 bytes longer. Since some other reads of compressed data
fails on the complements, there is one value which is being read far too much.
So there is probably a single length or distance which is read incorrectly
probably by a few bits.
15:13
The else if is accurate though.
15:16
And the incorrect number of bytes read is correct. But the line is:
distancetree.getValue(this. int dhclen = -1 :)
The -1 :
comes from the ternary operator on line 328. That also then has the
right length. So really if the length were messed up the bytes that appear
would be more or less. So these should be two separate windows. Then on the
following line there is:
\t\t\telse if ere may only be at most5de. (The
The starting tabs and the else if are correct. So not all distance codes are ruined. The distance code at that specific point however is. So I will need to debug writes of compressed windows. Since the length codes are correct, the only thing it would have to be is distance.
15:41
So this is the area when the window data is dumped:
DEBUG -- Window len= 285 max= 285 dist=3392 `????// Literal byte valu...
DEBUG -- Window len= 14 max= 14 dist=3392 `getValue(this.`
DEBUG -- Window len= 14 max= 14 dist=4180 `?int dhclen = `
DEBUG -- Window len= 4 max= 4 dist=4561 `-1 :`
DEBUG -- Window len= 12 max= 12 dist= 203 `????else if `
The doc says The extra bits should be interpreted as a machine integer stored
with the most-significant bit first, e.g., bits 1110 represent the value 14.
This makes me wonder.
16:14
Distance 4180 means code 24 11 4097-6144
.
16:18
The first failed window is at 12602, offset by the window is 8422. Actually the
distancetree.getValue(this.
is incorrect it should be
__readBits(5, true));
. Which means the 285 above would be incorrect because
that would include the distancetree.getValue
. That sequence is:
????// Literal byte value????if (code >= 0 && code <= 255)?????__write(cod
e, 0xFF, false);???????// Stop processing????else if (code == 256)?????ret
urn;???????// Window based result????else if (code >= 257 && code <= 285)?
????__decompressWindow(__handleLength(code),??????distancetree
So there are 18 extra lengths. So it is an incorrect length read.
16:25
Looking at the original file, there is a newline and 5 tabs. However the
extra length of what should not be there is 12 (all of distancetree
). So the
length is off by 12. So since the length is 285 that means the code is invalid
because the length will never exceed 258.
16:38
So the exception I put in does not trigger.
16:39
Actually, I found it
// If the code is 285 then the length will be that
if (__c == 285)
return 285;
16:45
The length is capped at 258, I blame similar numbers.
17:06
Ok, now I have to fix the issue reading the none block at the very start of a file.
17:19
Actually PNGs are not working properly because PNG uses Zlib and not raw deflate. So it would help to implement Zlib.
20:31
Actually the zlib stream is not regioned.
21:13
Well this one manifest has a BOM, did not believe I would have seen such a thing.