Bug Reports

[ztrumpet]

There is some wacky bug with the inData() command.  (This is tested with the most recent version of Axe, 1.1.0, on a TI 84+SE running 2.43)

This code comes straight out of Detonate.  I'm sure it can be triggered in other situations as well, but this is how I ran into it.
I am using inData for a collision check with my explosions.  If you need to see more code than what I provide here, I can give that to you, but I think this should be sufficient:

Here's my code that should have worked, but didn't:

: 0->{T+L4}^r->{P+L5}^r
: !If inData(r3*16+r4+1->N,L4)
: !If inData(N,L5)
: N->{P+++L5-1}
: End
: End

The code inside the second !If would be skipped even if it was supposed to be executed on some occasions.  This code deals with bombs being detonated in my game, and sometimes the bombs wouldn't be set off, which happened if the second !If was erroneously skipped.  By adding more/less code at the beginning of my program I could change where the bomb would fail to be detonated, but I never saw a pattern.

This code, however, works, proving that it's an Axe bug and not my own code at fault:

: 0->{T+L4}^r->{P+L5}^r
: !If inData(r3*16+r4+1->N,L4)
: 0->{P+L5}^r
: !If inData(N,L5)
: N->{P+++L5-1}
: End
: End

Like I said, let me know if you need more info.  I can give you my source if you need it; it's no trouble at all.

[Runer112]

Sorry to say it, but it is your code's fault. This line is the problem:

:0→{T+L₄}ʳ→{P+L₅}ʳ

The value left in hl after storing a number to a constant pointer is the original value you stored. But when storing a 2-byte number to a non-constant pointer, the value left in hl is pointer+1.

[ztrumpet]

Sorry to say it, but it is your code's fault. This line is the problem:

:0→{T+L₄}ʳ→{P+L₅}ʳ

The value left in hl after storing a number to a constant pointer is the original value you stored. But when storing a 2-byte number to a non-constant pointer, the value left in hl is pointer+1.

And now I feel really, really dumb.  I should have remembered to check that.
Thanks, Runer, and I'm glad to hear this isn't Axe's fault.

[squidgetx]

I guess that it is now a better coding habit to use less-hackish constructions since the peephole optimizer can handle it now....

But I've made it a habit to write optimized code as I go
I love it when I can optimize lines into just a single expression that doesn't get stored anywhere (Or commands with no arguments). It looks useless but it's not.

[Freyaday]

It's scary how unreadable optimized Axe can get.

[Darl181]

I'm not sure if this is related to Axe (1.1.0) or zStart (1.3.005) so I'll just post it here because that's where it started.

I used ON to exit from compiling a program, and zStart's hooks got disabled somehow.  When I ran the zStart app, it crashed.

[Runer112]

I think in the process of fixing replacements in Axioms in 1.1.0, another bug was introduced. Now, if I reference an Axe command or another Axiom command in my Axiom, I get two copies of the referenced command in the compiled code.

[Runer112]

You know how the problem with error scrolling was the longest standing bug in Axe until a few days ago? Well I just discovered a bug that came into existence only 11 days after it and is now contending for the title! The bug involves printing tokens to the graph screen, which has apparently been broken since it was first added. The issue is that the routine feeds B_CALL(_Get_Tok_Strng) the token in hl, although the bcall actually reads the token pointed to by hl.

7 days to release a version of Axe with this bug fixed, or else this (rather lame) bug takes the title of longest standing bug in Axe!

[Freyaday]

Is it possible this bug could have other side effects?

[willrandship]

I don't think it would have very much leeway in affecting other things, since it's just reading from the wrong spot to print stuff on screen. Worst case scenario: You accidentally Print an unreadable char and something happens (do those even exist in TI-ASCII?)

[Darl181]

Also, I've had a few problems with the instant goto.  I'd get err:parenthesis and goto.  Editing is fine, but once I quit some program or another will sometimes have an edited name (ie one time the archived program "SDOTRUN2" became SDOTRU►2").  thepenguin's archive cleaner fixes it, btw, but it's still kind of concerning..

This just happened again in Axe 1.1.1.  I can't get wabbitemu to replicate it, but it changed prgmSPRITES to prgmSPRITE► .  Evidently it's not just Err:Parenthesis, this time it happened on an Err:missing program.
The program whose name was corrupted was in the archive, btw.  I think it was the previous time, too.

Edit:  Just noticed this corruption is six letters into the program name as well.

[Quigibo]

Hmm interesting.  I'll look into it, it might have something to do with the parsing of sub-programs.

[Happybobjr]

when using files, the Y# has to be at the beginning of the statement.

Pt(x,y, 5+Y1) would fail, where
Pt(x,y, Y1+5) would work.

[Quigibo]

Neither of those should work.  Files only work with a handful of commands.  The sprite commands are not included in those.

[Happybobjr]

opps your right...  i use copy.

Copy(Y1+(B*3), L1 , 10) would work.
Copy(B*3+Y1, L1 , 10)  would fail, where