### Author Topic: Bug Reports  (Read 172896 times)

0 Members and 2 Guests are viewing this topic.

#### Quigibo

• The Executioner
• CoT Emeritus
• LV11 Super Veteran (Next: 3000)
• Posts: 2031
• Rating: +1075/-24
##### 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!

#### jacobly

• Posts: 205
• Rating: +161/-1
##### 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: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ʳ. « Last Edit: December 11, 2011, 05:40:58 am by jacobly » #### Happybobjr • James Oldiges • LV11 Super Veteran (Next: 3000) • Posts: 2325 • Rating: +128/-20 • Howdy :) ##### 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: １.０.0 TI-84 +SE ||| OS: 2.53 MP (patched) ||| Version: "M" TI-Nspire ||| Lent out, and never returned ____________________________________________________________ #### Builderboy • Physics Guru • CoT Emeritus • LV13 Extreme Addict (Next: 9001) • Posts: 5673 • Rating: +613/-9 • Would you kindly? ##### 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 #### leafy • CoT Emeritus • LV10 31337 u53r (Next: 2000) • Posts: 1554 • Rating: +475/-97 • Seizon senryakuuuu! ##### 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 (...) #### 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... ##### 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: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.
« Last Edit: December 11, 2011, 03:58:30 pm by Quigibo »
___Axe_Parser___
Today the calculator, tomorrow the world!

#### squidgetx

• Food.
• CoT Emeritus
• LV10 31337 u53r (Next: 2000)
• Posts: 1881
• Rating: +503/-17
• rawr.
##### 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]
[]->GDB1Although this:
Code: [Select]
Data()->GDB1currently can function as a replacement.

#### jacobly

• Posts: 205
• Rating: +161/-1
##### 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.

#### calc84maniac

• eZ80 Guru
• Coder Of Tomorrow
• LV11 Super Veteran (Next: 3000)
• Posts: 2897
• Rating: +467/-17
##### 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

#### Builderboy

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

#### ben_g

• Hey cool I can set a custom title now :)
• LV9 Veteran (Next: 1337)
• Posts: 1002
• Rating: +125/-4
• Asm noob
##### 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

#### Quigibo

• The Executioner
• CoT Emeritus
• LV11 Super Veteran (Next: 3000)
• Posts: 2031
• Rating: +1075/-24
##### 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!

#### Quigibo

• The Executioner
• CoT Emeritus
• LV11 Super Veteran (Next: 3000)
• Posts: 2031
• Rating: +1075/-24
##### Re: Bug Reports
« 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].
« Last Edit: December 14, 2011, 06:05:14 am by Quigibo »
___Axe_Parser___
Today the calculator, tomorrow the world!

#### 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.
##### 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.
If I'm wrong, please correct me!
Unfinished Projects:
 Elmgon 14% Basic Movement Demo Homescreen Game Pack 80% Basic Latest Release Cube Droid Saves the Galaxy 65% Axe Demo Detonate 70% Axe
Completed Projects:
Exodus | Midnight |Drifter | Axe Snake | Jump! | Factory Theta | Spider | Plot Drop | Papi Jump | Numb3rs | Nibbler | Boost | Duel Tile Map Editor | Homescreen Map Editor | Key Group Check | Oasis

#### FloppusMaximus

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:
xor ald (keyExtend), abcall GetKey ; or GetKeyRetOff, whateverld hl, (keyExtend-1)ld l, aThat way, every keycode is unique and consistent across all OSes.