Author Topic: Bug Reports (Read 455539 times)

Quigibo · « **Reply #1620 on:** December 09, 2011, 07:57:45 pm »

Oh crap, thanks! I forgot about that command when I split up the multiply. Fixed.

jacobly · « **Reply #1621 on:** December 11, 2011, 03:11:59 am »

Although the new getKeyʳ is more useful, it can also now be very confusing. For example:

:Repeat getKeyʳ=64
:End

Could cause an infinite loop that may be impossible to get out of, if lowercase is enabled.

The reason for this is that if you type a lowercase letter, it is stored at $8446, but if you type any other key, it does not reset the value at $8446. (Edit: This causes all of the other keycodes to change to different values every time a lowercase letter is typed.) On the plus side, its value does seem to always be reset at the beginning of the program.

Some fixes for this are to only read $8446 if a >= $fc, reset $8446 after it is read, or to change checks for any key that is not a lowercase letter to getKeyʳ^256=key code.
Edit: And in the last case, it should probably be documented somewhere, since it is not obvious just from playing around with getKeyʳ.

Happybobjr · « **Reply #1622 on:** December 11, 2011, 10:39:42 am »

I got a incorrect # of arguments error, but unarchiving the program fixed it

Builderboy · « **Reply #1623 on:** December 11, 2011, 01:24:38 pm »

I've gotten random errors from time to time that archiving/unarchiving fixes. o.O

leafy · « **Reply #1624 on:** December 11, 2011, 01:34:34 pm »

I second this. I'm always like - sigh, compiling error. Let's unarchive to see where the problem is. Oh - no error now?

Quigibo · « **Reply #1625 on:** December 11, 2011, 03:57:48 pm »

Quote from: jacobly on December 11, 2011, 03:11:59 am

Although the new getKeyʳ is more useful, it can also now be very confusing. For example:
Code: [Select]
:Repeat getKeyʳ=64 :EndCould cause an infinite loop that may be impossible to get out of, if lowercase is enabled.

The reason for this is that if you type a lowercase letter, it is stored at $8446, but if you type any other key, it does not reset the value at $8446. (Edit: This causes all of the other keycodes to change to different values every time a lowercase letter is typed.) On the plus side, its value does seem to always be reset at the beginning of the program.

Some fixes for this are to only read $8446 if a >= $fc, reset $8446 after it is read, or to change checks for any key that is not a lowercase letter to getKeyʳ^256=key code.
Edit: And in the last case, it should probably be documented somewhere, since it is not obvious just from playing around with getKeyʳ.

That's weird, it was getting reset in all of my testing so I assumed it would always reset. I'll fix that.

Also its weird those issues with archive are occurring again. I fixed that a while ago, but maybe something changed. It definitely sounds like a page boundary issue to me.

squidgetx · « **Reply #1626 on:** December 11, 2011, 10:00:22 pm »

Pointer declarations using empty brackets fails in the new version
Stuff like this:

Code: [Select]

[]->GDB1

Although this:

Code: [Select]

Data()->GDB1currently can function as a replacement.

jacobly · « **Reply #1627 on:** December 12, 2011, 11:33:01 pm »

This is from Commands.htm:

EndIf EXP		In loops, it works just like a regular "End" if the condition is true. But it will exit the loop if the condition is false.
End!If EXP		In loops, it works just like a regular "End" if the condition is false. But it will exit the loop if the condition is true.

But according to the way Axe behaves, shouldn't it be something like this:

EndIf EXP		In loops, it will exit the loop if the condition is true. But it works just like a regular "End" if the condition is false.
End!If EXP		In loops, it will exit the loop if the condition is false. But it works just like a regular "End" if the condition is true.

calc84maniac · « **Reply #1628 on:** December 12, 2011, 11:36:16 pm »

THIS. I always mixed up what those commands did because of the strange way in which they were documented.

Builderboy · « **Reply #1629 on:** December 12, 2011, 11:39:33 pm »

My, that is confusing

good catch!

ben_g · « **Reply #1630 on:** December 13, 2011, 04:22:53 pm »

I got an invalid axiom error, when my axiom was a program and archived. Unarchiving fixed it and it works both archived and unarchived if the axiom is an appvar

Quigibo · « **Reply #1631 on:** December 13, 2011, 07:13:11 pm »

That's not a bug, Axioms must be appvars in order to work. Axe only allows them as programs for the purpose of converting since most assemblers cannot natively export an appvar. Axe cannot convert the program for you if it is in archive, so it errors. The reason I cannot unarchive, convert, and then rearchive is because the entire edit buffer is used during compiling.

Quigibo · « **Reply #1632 on:** December 14, 2011, 06:01:57 am »

I fixed the error scrolling!!!

The trick was to learn how those stupid edit buffers actually work. In case anyone is interested, I will explain the problem because you never know who will need it. Basically the edit buffer moves all programs other than the one you are editing to the end (or beginning?) of RAM so that the buffer you have to work with is consecutively: All of free ram followed by the original program. The original program is then copied to the start of the free ram (so now there are 2 copies).

Here is where the error comes in. What happens when the program you're editing takes up more than the available ram in your calculator? (e.g. editing an 8Kb program when you only have 4Kb of ram left). You obviously don't have room for 2 copies, so one of them has to get cut. The way I was shifting the edit buffers originally, I was assuming that the original program at the end of free ram would get cut so the copy could be edited. But instead, the top program was truncated. So all I had to do was just use the handy ldir (Axe's Copy() command) to copy the original into the editing spot. From here on, the rest of the code works the way its supposed to now that the buffers are corrected.

This is Axe's longest solution-less bug to be fixed! The second longest was probably re-enabling interrupts correctly (Solved by our clever calc84maniac)

This also means error scrolling can finally be automatic since it won't ever crash. No need to press [prgm] anymore, it will always take you to the error unless you press [clear].

ztrumpet · « **Reply #1633 on:** December 14, 2011, 07:17:07 am »

Awesome!

Quote from: Quigibo on December 14, 2011, 06:01:57 am

This also means error scrolling can finally be automatic since it won't ever crash. No need to press [prgm] anymore, it will always take you to the error unless you press [clear].

Does error scrolling work even if the program being compiled is in archive? Thepenguin added a place for you to chain into zStart for that to happen, and it would certainly be a wonderful addition to Axe.

FloppusMaximus · « **Reply #1634 on:** December 14, 2011, 10:08:23 pm »

Quote from: jacobly on December 11, 2011, 03:11:59 am

Some fixes for this are to only read $8446 if a >= $fc, reset $8446 after it is read, or to change checks for any key that is not a lowercase letter to getKeyʳ^256=key code.
Edit: And in the last case, it should probably be documented somewhere, since it is not obvious just from playing around with getKeyʳ.

I haven't been following this discussion, but I think you mean A ≥ $FB (kExtendEcho3), not $FC. kExtendEcho3 was added in OS 1.15, and is used for various new tokens as well as the TI-Keyboard keycodes. Confusingly, $FB was used as a keycode in older OSes (kwnA) but it wasn't a prefix. For compatibility, I'd recommend that you zero keyExtend before calling GetKey:

Code: [Select]

xor a
ld (keyExtend), a
bcall GetKey ; or GetKeyRetOff, whatever
ld hl, (keyExtend-1)
ld l, a

That way, every keycode is unique and consistent across all OSes.

Author Topic: Bug Reports (Read 455539 times)

Quigibo

Re: Bug Reports

jacobly

Re: Bug Reports

Happybobjr

Re: Bug Reports

Builderboy

Re: Bug Reports

leafy

Re: Bug Reports

Quigibo

Re: Bug Reports

squidgetx

Re: Bug Reports

jacobly

Re: Bug Reports

calc84maniac

Re: Bug Reports

Builderboy

Re: Bug Reports

ben_g

Re: Bug Reports

Quigibo

Re: Bug Reports

Quigibo

Re: Bug Reports

ztrumpet

Re: Bug Reports

FloppusMaximus

Re: Bug Reports