Bug Reports

[Runer112]

I can't see why that would cause an issue, MGOS. Since I can't seem to replicate the issue in a small test program, perhaps the issue is a context/size issue. If you could post either the source program or the compiled executable, perhaps someone could discover the problem through debugging. If it's for a contest, be careful not to post anything that the contest rules forbid posting.

And you should be able to use {L₁}++ just fine, I see no sign that this would trigger any bugs.

[MGOS]

Ok. I can't post more, and I don't think it will help that much. The executable is now about 4k large and compiled to axe fusion atm. I will change that to an App because I will never be able to be under the 8k limit. It uses a lot of Filling/Copying for fast drawing on parts of the screen and the whole data is stored in L1 and L2 if that helps.The rest is just very standard axe stuff.

[kindermoumoute]

There is a bug with inData command : "If not found, 0 is returned.", it don't work, it returns the zero's location in list. Currently I can't use inData() without this syntax : inData(XX,XXX)-29??0,+29 ==> that's an ugly piece of code. x)

Can you solve this bug ?

[jacobly]

The only reason inData( would return the index of the 0, is if you were searching for 0.

Edit: If you wanted 0 if byte is 0, you could do BYTE?inData(,PTR).
Also, I can't help but mention that inData(BYTE,PTR)-29??0,+29 optimizes to inData(BYTE,PTR)-29?+29.

Edit 2: Alternatively, if BYTE can not be 255, you can do inData(BYTE+1,PTR), where every byte in PTR has been incremented by 1.

[squidgetx]

I think that app writing freezes if garbage collection needs to be done and/or at least not enough free space for the app

(What happened:

-Writing 0% freeze -> battery pull -> RAM clear -> repeat -> unarchive program (11k) -> changed name of executable -> rearchive -> prompt garbage collect -> garbage collect -> now it works )

[Runer112]

Here's a bug that seems to have plagued Stefan Bauwens in the recent contest. It boils down to these three lines of code:

Code: Select All | Copy To Clipboard

1 2 3 4

Buff(54)→°CA #Realloc(°CA) °A-2→°CE

The issue appears to be that, during the first pass, the A-theta variables haven't been assigned their proper addresses because °CA is not yet known. This then results in °CE being defined with a false value. I would say the bug isn't that °CE is defined with the incorrect value, but that an error isn't thrown. Pointers to variables should not be allowed to be used in constant definitions.

[Hayleia]

I have a stupid error.
See, each time the source is archived, the parser finds an "INVALID TOKEN" but not always at the same place. Sometimes it is 11113, sometimes it is 11727

Usually, when I get an invalid token, unarchiving, recompiling, rearchiving and recompiling fixes the problem but there it doesn't.

(note that I am not talking about the "Out of memory" thing that obviously comes from the fact that I run out of memory)

[Freyaday]

This has been plaguing me for a while.
Nymless crashes when you win, but only if compiled in 1.1.2
I caught it in Wabbit though.
Everything is in the .zip file.

[Hayleia]

I don't know if that was already reported but here is an easy to fix bug: there is a typo in "Invalid file use"

[Runer112]

Spot the problem!

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11

p_TextStrApp: .db __TextStrAppEnd-$-1 __TextStrAppLoop: ld a,(hl) or a ret z inc hl B_CALL(_VPutMap) jr nc,__TextStrAppLoop __TextStrAppEnd:

[calc84maniac]

Took me a little while, but... no ret at the end?

[Freyaday]

A minor interface bug/optimization: the numbers for size continue to update after the first pass.

[Freyaday]

I've got a nasty one.
I tried this:

GetCalc("_LLIST",11)

Which generated an OS list of eleven elements.
The list seemed to be fine, and contained all zeroes according to the homescreen.
And then I deleted it.
I got a BSOD.
I took the battery out and let the capacitors discharge, and the calc was back to normal, albeit with cleared RAM.

[Runer112]

This is the effect of neither the OS nor Axe properly handling lists and matrices when creating arbitrary variables. Lists and matrices don't have the normal 2-byte size header that programs and appvars do; lists have a 2-byte header with the number of 9-byte elements, and matrices have two 1-byte entries for number of elements in each dimension. However, the arbitrary variable creation B_CALL doesn't handle lists or matrices in any special way, so the OS only allocates as many bytes as the size argument you pass to it and writes that value to the variable header. So GetCalc("L₁",10) would cause the OS to allocate 10 bytes in RAM (+2 bytes for the header) and write $000A to the header. However, after it's created, if the OS subsequently looks at it, it will think it's a list with 10 elements, and thus much larger. Deleting this will result in deleting more memory than was allocated, causing your crash.

A special case for lists and matrices could be added to Axe, but I think that would add too much size for such rarely-created variable types. You can correct it manually yourself fairly easily though, like this:

Code: Select All | Copy To Clipboard

1 2 3 4 5

!If GetCalc("L₂",N*9)→L .Error End N→{L-2}ʳ

Or, optimized:
EDIT: calc84maniac says this may be unsafe, so for the costs of 2 bytes, perhaps just skip it.

Code: Select All | Copy To Clipboard

1 2 3 4

!If N→{GetCalc("L₂",N*9)→L-2}ʳ+1 .Error End

[Freyaday]

Thanks, Runer. There was some discussion about whether or not this was actually a bug. >.>
At least now a decision has been reached about what to do with it.