Author Topic: Bug Reports (Read 454152 times)

pimathbrainiac · « **Reply #1950 on:** June 04, 2015, 09:25:03 am »

Is the development version on http://axe.eeems.ca still usable, out of curiosity?

Runer112 · « **Reply #1951 on:** June 04, 2015, 04:15:05 pm »

I believe it's the same build, or if not, very close. Both should just be 1.2.2 with a couple of improvements, so they should be stable.

jacobly · « **Reply #1952 on:** September 07, 2015, 03:43:06 am »

Code: (Axe) [Select]

Copy(,,∗{Y₁})
            ^
  ERROR
PARENTHESIS

It appears that the } is closing the Copy( command. It seems that the operator has to be one that uses a subroutine, such as ∗, ^, or /.

Runer112 · « **Reply #1953 on:** September 08, 2015, 02:34:41 pm »

I'm aware that operations with file pointers are implemented in an ugly way internally, so I'm not too surprised by this bug. I can look into it more, but honestly I'm not sure if I'll be able to fix it. I've somewhat accepted by now that file pointers are a bit broken.

EDIT: Looks like I unknowingly already fixed this in Axe 1.3.0. I should really get that to a full release state...

c4ooo · « **Reply #1954 on:** November 29, 2015, 09:54:03 pm »

There is a major bug related to inline custom named vars:

Code: [Select]

Line({*xpos},{*ypos},+5,+5works fine while

Code: [Select]

Line(xpos,ypos,+5,+5currupts the ram / crashes the calc
(The star is the angle circle thing)

Runer112 · « **Reply #1955 on:** November 29, 2015, 10:35:29 pm »

Quote from: c4ooo on November 29, 2015, 09:54:03 pm

There is a major bug related to inline custom named vars:
Code: [Select]
Line({*xpos},{*ypos},+5,+5works fine while
Code: [Select]
Line(xpos,ypos,+5,+5currupts the ram / crashes the calc
(The star is the angle circle thing)

I can't seem to reproduce this in my small test program. Would you be able to provide the source and/or compiled programs that are causing this?

c4ooo · « **Reply #1956 on:** November 30, 2015, 07:03:33 am »

Code: [Select]

Fix 5
ClrDraw^^R
0->PITCH
10-->XPOS
20->YPOS
REpeat getKey(41)
ClrDraw
If getkey(1)
PITCH<<32?PITCH++
elseif getKey(4)
PITCH>>-32?PITCH--
end
sin(PITCH-32)->S
cos(PITCH-32)->C
Text(0,0,abs(PITCH)>Dec
Line(XPOS,YPOS,C-S//16+XPOS,S+C//16+YPOS
DispGraph
Return
L5->*XPOS+2->*YPOS+2->*PITCH+2->*THROTLE

The bug may as well be somewhere else. Also i am using axe 1.3.0,the download you released on one of the threads

Haobo · « **Reply #1957 on:** December 01, 2015, 03:51:28 pm »

The only thing that I see wrong is a bunch of syntax mistakes, which I guess you didn't directly copy and paste this from some IDE. If you move the last line to the top though, there doesn't seem to be any errors. It works perfectly fine when I tested it on wabbit. Here's a file that should work for what you have.

Also, just some stuff, you should probably close your parenthesis since that doesn't make it faster or smaller, only improve readability, and use DispGraphClrDraw instead of them individually, makes it a lot faster.

Eeems · « **Reply #1958 on:** December 01, 2015, 09:10:01 pm »

Quote from: Haobo on December 01, 2015, 03:51:28 pm

The only thing that I see wrong is a bunch of syntax mistakes, which I guess you didn't directly copy and paste this from some IDE. If you move the last line to the top though, there doesn't seem to be any errors. It works perfectly fine when I tested it on wabbit. Here's a file that should work for what you have.

Also, just some stuff, you should probably close your parenthesis since that doesn't make it faster or smaller, only improve readability, and use DispGraphClrDraw instead of them individually, makes it a lot faster.

Due to how limited memory is on a calculator, you would usually forgo readability for smaller size code. It's recommended in Axe and Basic to drop the tailing quotes/parenthesis and save space due to them being implicitly added by a newline. When posting the code for others to read it's totally fine to add them in, but when actually storing them on calculator, every extra byte of space is needed.

E37 · « **Reply #1959 on:** December 03, 2015, 05:06:40 pm »

One of the games I am creating runs fine with 1.2.2 but on 1.3.0 the the gravity function doesn't work.
I am using pxltest for gravity and there is no complex physics just up or down (no velocity).
I am using the S variable for remaining jump.

Eeems · « **Reply #1960 on:** December 03, 2015, 08:57:33 pm »

Quote from: E37 on December 03, 2015, 05:06:40 pm

One of the games I am creating runs fine with 1.2.2 but on 1.3.0 the the gravity function doesn't work.
I am using pxltest for gravity and there is no complex physics just up or down (no velocity).
I am using the S variable for remaining jump.

You're probably going to want to post some example code so that @Runer112 can attempt to recreate the issue and debug it.

neuronix · « **Reply #1961 on:** December 04, 2015, 12:04:46 pm »

If compile any axe program with Axe 1.3, the calculator freeze

Runer112 · « **Reply #1962 on:** December 04, 2015, 12:55:41 pm »

Quote from: neuronix on December 04, 2015, 12:04:46 pm

If compile any axe program with Axe 1.3, the calculator freeze

Could you provide more information? The following questions come to mind:

Does pressing VARS or ON do anything?
Does archiving/unarchiving the source change anything?
Have you ever successfully compiled something with Axe 1.3.0, or has this only just started happening?
Precisely when does it freeze? Does this seem to be the same in every program?
What are Axe's options set to? Particuarly, are you compiling as an applcation or is auto backup enabled?
What model calculator are you using? If you also use an emulator with that calculator's ROM image, does the freeze also occur on the emulated calculator?

E37 · « **Reply #1963 on:** December 04, 2015, 01:39:02 pm »

The game I am creating is an experiment in “Object Oriented Programming” I know that it really isn’t, I just like to tell myself it is.
Once I you the game with Axe 1.3.0 run it (duh) it, select play and use the side arrows to select at least 2 enemies (the game freezes if you pick just one - even when compiled with 1.2.2), then hit enter.
The character is the little x. Usually the character falls but it just floats.
The numbers are used for debugging, the first is remaining jump and the second is how many pixels the game thinks are directly under a player (with 1.2.2 the second number never exceeded three.)
Sorry I can’t supply a screenshot, Ti-connect is acting weirdly.
The compile time with 1.3.0 is AMAZING!
Keep up the great work!

edit:The code that seems to be broken is:

Code: [Select]

0 -> Y:For(X,0,2
Y+Pxl-Test(25+Y,25)->Y
End

When I closed the parenthesis on the For( loop the statement worked just fine.
edit2: That doesn't seem to be the only problem... While closing the parenthesis worked in the test program it didn't fix the game.
I can't quite pin it down but it seems to have something to do with addition.
Using the Text command I found that after

Code: [Select]

0 ->Y:For(X,0,2)
Y + Pxl-Test(A+X-1,B+2) -> Y
End

Y ends up with a value over 40000!
But changing the code inside the loop to:

Code: [Select]

Pxl-Test(A+X-1,B+2)
+Y -> Y

gives the right value! (the bug never appears when compiled with 1.2.2)
This code is in the program PLAYER in the group.
(Sorry for the brain-dump style of writing)

_{Edit (Eeems): Code tags}

E37 · « **Reply #1964 on:** May 17, 2016, 04:46:00 pm »

I found a bug!
PRGM:NAME
.CAKE
Disp t sub( >Dec
Disp {GetCalc("prgmTOK")}r >Dec

PRGM:TOK
sub(

The t before sub( is the token character.
The two values are not the same.
The t doesn't get two byte tokens correctly. (I think this is a bug... maybe I'm missing something)

Author Topic: Bug Reports (Read 454152 times)

pimathbrainiac

Re: Bug Reports

Runer112

Re: Bug Reports

jacobly

Re: Bug Reports

Runer112

Re: Bug Reports

c4ooo

Re: Bug Reports

Runer112

Re: Bug Reports

c4ooo

Re: Bug Reports

Haobo

Re: Bug Reports

Eeems

Re: Bug Reports

E37

Re: Bug Reports

Eeems

Re: Bug Reports

neuronix

Re: Bug Reports

Runer112

Re: Bug Reports

E37

Re: Bug Reports

E37

Re: Bug Reports