Author Topic: Bug Reports  (Read 462067 times)

0 Members and 1 Guest are viewing this topic.

Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Bug Reports
« 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.
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline jacobly

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 205
  • Rating: +161/-1
    • View Profile
Re: Bug Reports
« 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:
Code: [Select]
: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ʳ.
« Last Edit: December 11, 2011, 05:40:58 am by jacobly »

Offline Happybobjr

  • James Oldiges
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2325
  • Rating: +128/-20
  • Howdy :)
    • View Profile
Re: Bug Reports
« Reply #1622 on: December 11, 2011, 10:39:42 am »
I got a incorrect # of arguments error, but unarchiving the program fixed it
School: East Central High School
 
Axe: 1.0.0
TI-84 +SE  ||| OS: 2.53 MP (patched) ||| Version: "M"
TI-Nspire    |||  Lent out, and never returned
____________________________________________________________

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Bug Reports
« 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

Offline leafy

  • CoT Emeritus
  • LV10 31337 u53r (Next: 2000)
  • *
  • Posts: 1554
  • Rating: +475/-97
  • Seizon senryakuuuu!
    • View Profile
    • keff.me
Re: Bug Reports
« 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?
In-progress: Graviter (...)

Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Bug Reports
« Reply #1625 on: December 11, 2011, 03:57:48 pm »
Although the new getKeyʳ is more useful, it can also now be very confusing. For example:
Code: [Select]
: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ʳ.

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.
« Last Edit: December 11, 2011, 03:58:30 pm by Quigibo »
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline squidgetx

  • Food.
  • CoT Emeritus
  • LV10 31337 u53r (Next: 2000)
  • *
  • Posts: 1881
  • Rating: +503/-17
  • rawr.
    • View Profile
Re: Bug Reports
« 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.

Offline jacobly

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 205
  • Rating: +161/-1
    • View Profile
Re: Bug Reports
« 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.

Offline calc84maniac

  • eZ80 Guru
  • Coder Of Tomorrow
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2912
  • Rating: +471/-17
    • View Profile
    • TI-Boy CE
Re: Bug Reports
« 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.
"Most people ask, 'What does a thing do?' Hackers ask, 'What can I make it do?'" - Pablos Holman

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Bug Reports
« Reply #1629 on: December 12, 2011, 11:39:33 pm »
My, that is confusing O.O good catch!

Offline ben_g

  • Hey cool I can set a custom title now :)
  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1002
  • Rating: +125/-4
  • Asm noob
    • View Profile
    • Our programmer's team: GameCommandoSquad
Re: Bug Reports
« 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
My projects
 - The Lost Survivors (Unreal Engine) ACTIVE [GameCommandoSquad main project]
 - Oxo, with single-calc multiplayer and AI (axe) RELEASED (screenshot) (topic)
 - An android version of oxo (java)  ACTIVE
 - A 3D collision detection library (axe) RELEASED! (topic)(screenshot)(more recent screenshot)(screenshot of it being used in a tilemapper)
Spoiler For inactive:
- A first person shooter with a polygon-based 3d engine. (z80, will probably be recoded in axe using GLib) ON HOLD (screenshot)
 - A java MORPG. (pc) DEEP COMA(read more)(screenshot)
 - a minecraft game in axe DEAD (source code available)
 - a 3D racing game (axe) ON HOLD (outdated screenshot of asm version)

This signature was last updated on 20/04/2015 and may be outdated

Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Bug Reports
« 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.
« Last Edit: December 13, 2011, 07:14:21 pm by Quigibo »
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Bug Reports
« Reply #1632 on: December 14, 2011, 06:01:57 am »
 :crazy: I fixed the error scrolling!!! :crazy:

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].
« Last Edit: December 14, 2011, 06:05:14 am by Quigibo »
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline ztrumpet

  • The Rarely Active One
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5712
  • Rating: +364/-4
  • If you see this, send me a PM. Just for fun.
    • View Profile
Re: Bug Reports
« Reply #1633 on: December 14, 2011, 07:17:07 am »
Awesome!
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.

Offline FloppusMaximus

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 290
  • Rating: +57/-5
    • View Profile
Re: Bug Reports
« Reply #1634 on: December 14, 2011, 10:08:23 pm »
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.