I have a small feature wish right here!  Currently the percent completed meter can be meaningless if you have several included files in your program, the percent complete just seems to show random numbers because it's switching so fast.  Cal84 suggested it might be a good idea to have the percent compiled for included programs separate from the percent compiled for the main program (maybe not even include it at all?)  Perhaps directly to the right of the main percent, there could be a second percent when parsing included programs?  Just a suggestion

That's actually impossible because Axe doesn't know how large a program is when you have included programs.  It only knows the number of bytes read from the source as a percent of the total number of bytes.  There is no way I'd be able to calculate the expanded size unless I made a 3rd pass to do nothing but sum up the size of all the source programs recursively.  Alternatively, I could do that in the first pass so that the percent would be accurate during the 2nd pass, but most errors are caught in the first.

What I probably will end up doing is adding the name of the current program being parsed to the progress so the percent means something; the progress within the current file.

I have a question:
so, you import OS var by doing this, right?

Code: [Select]

GetCalc("varA"->B
float{B}->A
Now, is there a way to store that A into constant?

To answer the original question for the general case of GetCalc(), there actually IS a way to store it to a constant: you can copy the contents of the file to a known free-ram location (assuming the data in the file will fit there).  If done correctly, this can lead to both a speed and size optimization as well as making code easier to write since there are less arguments you need to pass around.  This of course comes at the cost of overhead loading time for the copy and reduces the amount of free-ram you have left.

EDIT: This probably wasn't the question you were asking, but it should help someone I'm sure.

I was going to keep it secret, but I'll tell you what I'm working on right now

Objects.  Axe currently only has one; the file (Using the Y₀ - Y₉ tokens).  I am creating a new object; the table (Using [A] - [J] tokens).  Its about time too, it was something I was trying to implement when I was first sketching out possible syntaxes before I started writing the parser.

A table is not a list, nor a matrix.  Its more like a SQL table if you're familiar with that.  The reason I'm able to have this structure in the first place is because I was finally able to optimize it enough given these invariants:

• The table has a fixed column width, but can grow and shrink the number of rows.
• The ordering of rows in the table should never matter and could change at any time.
• An entry in the table cannot be accessed directly, it must be iterated to that entry to modify or delete it.

Iterators are nestable by the way.  This type of structure is perfect for situations where you have to manage one or more list of objects in a room or simulation.  This is exactly what you need for: Physics simulators, bullet code, collision detection, fluids, enemies, etc.  I think this will be a major major utility to coders and will bring the version up to 1.1.  Hopefully I can get everything working soon.

That shouldn't compile so I guess its a bug then.  You can't assign a variable to a constant because, by definition, constants cannot change value throughout the life of the program.

The friends button currently doesn't do anything...  We're unsure if we're going to add any social features yet because simply sharing a location isn't really a social thing.  I mean how often would you actually use a feature like that?  We are thinking about other ways though.

One idea is like geo-tagged photos, but instead of just tagging a longitude-latitude which isn't useful at all unless you're viewing your photos on a map, it would actually tag them by the name of the place you're at and include a link to the place's page.  But this has its own problems in that it takes a long time to load the GPS indoors, more than most people are willing to wait to take a photo, and you wouldn't often take pictures outside unless you were next to a landmark or something.

Another idea is doing coupons/deals, but its not very scale-able to go around and asking all the small businesses in the US if they're interested in some kind of partnership.  And large companies and restaurant chains would be reluctant to do that unless we had tons and tons of users.

So we're still thinking of ways to expand it.  I'd love to hear of ideas if anyone can think of a way to make the app more useful (something you would realistically use all the time).

Ah, didn't think about that.  I will add that next version and update the docs.

Self modifying code for the purpose of speed optimization is not practical in Axe because by definition, you are modifying at the instruction level.  Since Axe does not deal with assembly instructions directly in its syntax, you would have no idea what instructions to change.  Instead what you want is self modifying code at the language level.

Suppose you have some long complicated routines:
:A+(B*C)-D->E

Lets say sometimes, you need to use * between B and C and other times you need a + and other times you need a - and occasionally you need a /.  So instead of writing 4 routines with an if statement to pick between them, you would like to self modify the code so you avoid if statements all together for "faster" code. (May or may not actually be faster in Axe) But from a high level programming point of view, you can imagine that modifying the code directly avoids having to make an extra check against one or more if statements.

The good news is that you actually CAN do this.  This is what lambdas were meant for and why they're so powerful.  The code can be written like this instead:
:A+(Z)(B,C)-D->E

:λ(r1*r2)->Z
:λ(r1+r2)->Z
:λ(r1-r2)->Z
:λ(r1/r2)->Z

Using any of the lambdas once modifies the code so that all future calls to the big routine will use the new operation until you set it something else.  You can use the same method for even more complicated things:

:(Z)(5,6,Pic1)

:LOr->Z
:LXor->Z
:LOff->Z

:Lbl Or
:Pt-On(r1,r2,r3)
:Return
:Lbl LXor
:Pt-Change(r1,r2,r3)
:Return
:Lbl LOff
:Pt-Off(r1,r2,r3)
:Return

So yes there is a way to sort of do self modifying code in Axe, but other than making it easier to code, it doesn't really optimize anything since SMC optimizations can really only come from the instruction level.

Here is an incredibly inefficient and slow way to do an "ex h,l" but its impressive that it uses no extra registers or memory.  Even the carry flag is preserved:
ExhHL:
  adc hl,hl
  adc hl,hl
  adc hl,hl
  adc hl,hl
  adc hl,hl
  adc hl,hl
  adc hl,hl
  adc hl,hl
  rl  lYou could do the same strategy with any 2 registers, although none as efficiently.  I guess this could be theoretically useful in a non-time sensitive situation when you need to do an exchange but all registers are in use including SP (so no stacks) and there is no more free ram, but I doubt anyone would be in that situation.