Freyaday, yes, that would be great.
But it should always backup BEFORE compiling
(sometimes it freezes while compiling apps!)

Axe doesn't back up before compiling because, if you made a lot of changes to a program and have introduced a number of bugs/compiling errors, you wouldn't want Axe to overwrite your old backup until all the errors have been dealt with and the program successfully compiles.

Also, it is strange that Axe sometimes freezes for you when compiling apps. Does it actually freeze, or does it just appear to be doing nothing for 5-10 seconds? Because the step of producing the actual application can take a decent amount of time, during which Axe may appear to be frozen. But if Axe is really freezing, are you using the latest version (1.0.3)? If not, try upgrading your version of Axe. If you are already using the latest version of Axe and are encountering genuine freezes, not just slow performance, I suggest submitting a bug report with as much information as you can about what causes/caused a freeze.

Axe should, after compiling an App, always check, if the new app exists, and if not, it should ask if it should try again, because axe made a mistake, or something like that!

Axe has never failed to create an application when I've tried to compile one. I don't think such an error handler is really necessary, since the error should never occur in the first place. If it does occur, you should try to give details about the situation as a bug report.

And another thing is, that it should be possible to add a new line in a code
writing into the code of a program, a command like "newline(" is still missing
It should be possible to tell it "newline(20)" and it should add a new line after the 20th symbol in the code

I've been scratching my head for a bit in response to this feature request. Can you elaborate on what you are suggesting?

A third thing:
A command like "GDB-grey("
It should be possible to show a GDB in greyscale, too. And it should be possible to controle, how dark every greyscale should be (like numbers from 1-10, 1 is white, 10 is black)
Because it's annoying if you have to try out, how often you must use DispGraph^r if you want to have a darker greyscale!!
Or if you neef one scrolling, and a non-scrolling greyscale-pic!!!

You can display any data you want as a grayscale image. In fact, it's now easier than ever to display grayscale images. This is done with DispGraph(image front buffer, image back buffer)^r/^rr. And regarding controlling the color of produced grays, remember that the calculator only has a black and white screen. It's pretty amazing that distinguishable grays can be produced at all.

Is there any better way to controle how darlk something should be?

Quote from: p2 on September 21, 2011, 10:31:22 am

And another thing is, that it should be possible to add a new line in a code
writing into the code of a program, a command like "newline(" is still missing
It should be possible to tell it "newline(20)" and it should add a new line after the 20th symbol in the code

I've been scratching my head for a bit in response to this feature request. Can you elaborate on what you are suggesting?

It sounds to me like he wants a newline feature, like in the program editor.  However, this is not a feature for Axe.  If a programmer would like to have this feature, it is a thing to handle on his/her end.  For instance:

:"TEXT[FF]NEWLINE[FF]ANOTHER LINE"->Str1
:
:sub(TXT,X,Y,Str1)
:
:Return
:
:Lbl TXT
:r1->r4
:For(I,0,length(r3))
:If {I+r3}->{L1}^r-255
:Text(r1,r2,L1)
:r4+4->r4
:Else
:r2+7->r2
:r1->r4
:End
:End

StorePic (Buffer1,Buffer2)
RecallPic (Buffer1,Buffer2)

Moving buffer data around can already easily enough by copying 768 bytes of data. The main reason StorePic and RecallPic were added is because they produce more optimized code since they work with set buffers. If they allowed variable buffers, they would hardly be any more optimized than simply doing Copy(Buffer1,Buffer2,768). And in response to Darl181, having versions of StorePic and RecallPic that copy two buffers would actually be less optimized than two individual single-buffer copies.

A far more interesting request would be for routines like Copy() to be able to have 8 different versions of itself, for all the possible combinations of constant and non-constant arguments.

How about being able to access the loop counter in single-argument for loops? This could be done especially easily if all loops used a simple 16-bit counter, but could also be done (albeit not so easily) with the other counter formats as well. It would be especially cool if you could access the loop counter for the loop that the current loop is nested in.

Something I think we forgot when discussing this on IRC a while ago is that you can't easily access that stack entry in the middle of an expression (where other values might be pushed onto the stack).

Perhaps it could be possible to have some syntax like:
:For(5→A)
:Disp A>Dec
:End
which would display
    5
    4
    3
    2
    1

Of course, what this would do is store the loop counter to the specified variable at the beginning of each loop-around.

Freyaday, I don't understand what you're trying to do in the code snippet.  What I think you might be trying to do is allow:
:If A
:Stuff
:Endto be written as:
A?Stuff
If so, that would not be physically possible due to the way Axe uses the stack.  There are several commands which MUST be "stack free" in order to run, Goto and Return are 2 of them.  This is the same reason why you cannot use those commands in a single argument for loop, so your first example would never work.  Some commands could work in there, but I would rather not use those since writing it the standard way is FAR less limiting.

I don't see the difference between the loop counter in a for loop and the regular for loop other than the fact that because it counts backwards to zero it can be slightly more optimized.  The single argument for loop as you are probably aware does not use a 16 bit register format, and requires 4 bytes of instructions to convert, and another 3 to write to the variable.

However, even though I don't think its necessary, I could always add a new 2-argument for loop For(A,5) for instance that counts down from 4 to zero (5 numbers total).  This might save around 3 bytes compared to a typical for loop since it doesn't need the subtraction

Okay, this feature request is a monster, but I think it could be the next step for huge code optimizations.

The feature is basically this: Allow the conditions of control statements such as If,While,EndIf,etc to check for something other than non-zero or zero.

I propose the following syntax:
Control value1!opvalue2

First, value1 is evaluated in HL. Then, value2 is evaluated and is compared with or applied to value1 using !op. Note that the entire expression on the right side of !op will be evaluated before the comparison. Also, in general, afterwards HL will still contain value1. Finally, the result of the comparison is used to decide whether to jump or not.

Here are some concrete examples:
.This works like If A<B, except it returns A instead of 0 or 1 and it is more optimized.
If A!<B
.Do stuff here
End

Generated ASM code:
  ld hl,(axv_A)
  ld de,(axv_B)
  ld a,l
  sub e
  ld a,h
  sbc a,d
  jp nc,end
  ;Do stuff here
end:

.This is like !If Ae0, but it returns A instead of 0 or 1 and is considerably more optimized.
!If A!e0
.Do stuff here
End

Generated ASM code:
  ld hl,(axv_A)
  bit 7,l
  jr nz,end
  ;Do stuff here
End
Here is a list of such operations I think would be worth implementing:
!=   //Equal
!≠    //Not equal
!<    //Less than
!>    //Greater than
!≤    //Less or equal
!≥    //Greater or equal
!<<   //Signed less than
!>>   //Signed greater than
!≤≤   //Signed less or equal
!≥≥   //Signed greater or equal
!e    //Bit set in 8-bit value
!ee   //Bit set in 16-bit value
! and //8-bit AND not zero
! xor //8-bit XOR not zero
! or  //8-bit OR not zero
      //(16-bit versions too?)
!+    //Unsigned carry detection for addition (returns value1+value2)
!-    //Unsigned carry detection for subtraction (returns value1-value2)
Edit: It has come to my attention that ! might be confusing. Perhaps a better syntax would be =?, <?, ee?, etc

Edit2: Optimized ASM code for speed (same size)