• Features Wishlist 5 1
Currently:  

Author Topic: Features Wishlist  (Read 378298 times)

0 Members and 2 Guests are viewing this topic.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Features Wishlist
« Reply #3450 on: December 09, 2015, 10:17:45 am »
Quote
[8:31:56 AM]   c4ooo   @runer do you think it will be possible to add #org() command specifying the call ofset?
[8:34:17 AM]   c4ooo   #org() - change org to default #org(int) - change org to int #rel(0/1) to force relative addresses to be used (1) / not used (0)[and give an error if needed]

It may be possible to allow changing of the code origin. Out of curiosity, what did you want this feature for?

However, I don't think a position-independent mode would be feasible. The CPU doesn't provide any instructions to support relative calls or memory accesses, and the only instructions that support relative jumps have a limited distance.

For the 2nd options page one option should to have zoom compile as default.
(Although 1.3.0's compile time is awesome anyways)
Also compile to archive would be cool also.
(so I don't have to archive a program after I compile it)
The ability to see hidden programs' names correctly would also be nice.
(Having my program's name start with some random character can make it sort of hard to tell them apart)

Although I am certainly looking for useful options to fill out the options menu in Axe 1.3.0, I'm not sure how I stand on a default zoom compile option. It doesn't save you any keypresses when compiling, you just have to press a different button to start compilation.

I do somewhat like the idea of an option to archive compiled programs. But I say "somewhat" because having your programs always archived does naturally feel more secure, but then I realize that if your program is buggy and crashes, do you really care about preserving it? Presumably, your next step will be to modify the source, either to attempt to fix the bug or add debug statements, and recompile anyways.

Regarding hidden programs, they're not a feature of the OS, just a hack of modifying the name to start with a strange character. And why would you want to hide an Axe source program, anyways? I can't see much benefit to having hidden Axe source programs, and without that, I don't see any reason to bother properly handling them.

Please feel free to try to add extra information to any of these ideas to sway me more towards supporting them. Despite how I may sound, I am open to additions, but I'd like to be fairly convinced that they will be worth it.

Offline c4ooo

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 252
  • Rating: +10/-1
  • The impossible chemical compound.
    • View Profile
Re: Features Wishlist
« Reply #3451 on: December 09, 2015, 03:48:15 pm »
Quote
[8:31:56 AM]   c4ooo   @runer do you think it will be possible to add #org() command specifying the call ofset?
[8:34:17 AM]   c4ooo   #org() - change org to default #org(int) - change org to int #rel(0/1) to force relative addresses to be used (1) / not used (0)[and give an error if needed]

It may be possible to allow changing of the code origin. Out of curiosity, what did you want this feature for?

However, I don't think a position-independent mode would be feasible. The CPU doesn't provide any instructions to support relative calls or memory accesses, and the only instructions that support relative jumps have a limited distance.
This would be helpfull for modular programs. What i would do is disallow data creation in rel(1) mode (so no inline data and stuff); and error if the jump is over the 127 byte limit.
-German Kuznetsov
The impossible chemical compound.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Features Wishlist
« Reply #3452 on: December 09, 2015, 04:51:59 pm »
In what context might a "modular program" be useful? Note that you'd also lose the ability to call functions, including all of Axe's built-in functions, which would really restrict what useful things one could do. You could possibly do more useful things with assembly, which seems to me like the more appropriate langauge in which to do tricky things like this anyways.
« Last Edit: December 09, 2015, 04:56:25 pm by Runer112 »

Offline c4ooo

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 252
  • Rating: +10/-1
  • The impossible chemical compound.
    • View Profile
Re: Features Wishlist
« Reply #3453 on: December 28, 2015, 10:19:53 am »
In what context might a "modular program" be useful? Note that you'd also lose the ability to call functions, including all of Axe's built-in functions, which would really restrict what useful things one could do. You could possibly do more useful things with assembly, which seems to me like the more appropriate langauge in which to do tricky things like this anyways.
My idea was to load the code into ram by sections, so that the program could be bigger. (But have some of its data in appvars) ;)
-German Kuznetsov
The impossible chemical compound.

Offline E37

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 306
  • Rating: +21/-0
  • Trial and error is the best teacher
    • View Profile
Re: Features Wishlist
« Reply #3454 on: January 17, 2016, 12:41:00 pm »
The ability to draw larger sprites such as 16 x 16 pixel sprites could be useful.
The option to run the program right after compile whithout having to go back to the home screen would be nice.
Having Axe back up all files compiled (if multiple programs are included with the prgmNAME command) could be helpful.
Axe could check if the program is the same before backing it up.
If you attempt to run a source code file it could compile then run.
A global offset for all drawling commands would be nice (for scrolling games). Basically if the offset is 3x and 2y pxl-on(0,0) would turn on a pixel at 3,2
The ability to write bytes directly to archive would be neat.
Add Memkit!!!
Pause until something happens, like pause until the enter key is pressed.
A command like Stop that makes the program quit rather than overflow an array.
A command to make a black hole!
The ability to make Axioms and to compile to appvar (possibly by having the first line .appvNAME instead of .NAME)
Maybe more areas of free RAM?
Larger apps?
Draw text to different buffers.
Make the Line( command show up even when one end is off the screen.
A feature for a 2-dimensional list (matrix) would also be useful.


These are just some ideas I don't know how may are possible or feasable.
« Last Edit: January 17, 2016, 01:24:45 pm by Runer112 »
I'm still around... kind of.

Offline Runer112

  • Project Author
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Features Wishlist
« Reply #3455 on: January 17, 2016, 03:27:59 pm »
The ability to draw larger sprites such as 16 x 16 pixel sprites could be useful.

The Bitmap() command does this.

The option to run the program right after compile whithout having to go back to the home screen would be nice.

Sounds like a good idea.

Having Axe back up all files compiled (if multiple programs are included with the prgmNAME command) could be helpful.

Also a good idea, although it turns out to be a bit tricky to implement this. But I can look into it.

Axe could check if the program is the same before backing it up.

Another good idea.

If you attempt to run a source code file it could compile then run.

This would require a parser hook, which would clash with any other parser hook used to implement running programs from the home screen or hybrid BASIC libraries, and would make all BASIC programs slightly slower. So this isn't worth it. However, this functionality would fit well into any apps that already provide such hooks, like zStart or DoorsCS.

A global offset for all drawling commands would be nice (for scrolling games). Basically if the offset is 3x and 2y pxl-on(0,0) would turn on a pixel at 3,2

This shouldn't really be the job of a drawing comamnd, and it wouldn't really be any more optimal to include the functionality built-in. The user's code should make such adjustments.

The ability to write bytes directly to archive would be neat.

This is, for mostly all intents and purposes, not possible. Additionally, I'm not comfortable giving user code the ability to, whether intentionally or accidentally, destroy archived data or the OS— or if something went horribly wrong, the boot code, which would brick the calculator.

Add Memkit!!!

Yes, this should really be done. It could never fit before, but with all the optimizations that 1.3.0 brought, it might fit now.

Pause until something happens, like pause until the enter key is pressed.

Adding a built-in just for this would be entering the realm of feature creep. This can be done very easily in user code: Repeat <something> : End.

A command like Stop that makes the program quit rather than overflow an array.

I don't understand what the "overflow an array" bit has to do with this, but if I'm understanding correctly otherwise, the Returnr command does this.

The ability to make Axioms and to compile to appvar (possibly by having the first line .appvNAME instead of .NAME)

Libraries coded in Axe should be just that: coded in Axe. This provides many benefits, including the ability to easily see/modify the source if necessary and receiving the benefit of future compiler optimizations. If you're interested in particular features of the axiom system that are unavailable to Axe programs, you should request those directly.

As for compiling as an appvar, I can probably make an appvar compile target.

Maybe more areas of free RAM?

There aren't really many sizable areas of "free" RAM remaining. The fact that there were 6 decent sections and that there are 6 numbered list variables was a rather happy outcome that will probably remain that way.

If you want to search for more RAM to use, consider checking out thepenguin77's list.

Larger apps?

Multi-page app development is hard enough in assembly when you have full control of paging. Coming up with a relatively painless way to provide multi-page app development to Axe code is even harder. I've brainstormed approaches in the past, but never came up with a satisfactory approach.

Draw text to different buffers.

The fact that text can only be drawn to the main buffer is a limitation of the OS's text drawing routines. Trying to replicate said routines would involve a number of obstacles that (from my perspective) simply aren't worth dealing with.

Make the Line( command show up even when one end is off the screen.

This request has been around for a long time, and it's definitely one that deserves to be implemented. But implementing it in a complete and relatively optimal manner is rather daunting and I haven't (nor has anyone else) been able to do so.

A feature for a 2-dimensional list (matrix) would also be useful.

Considering 1-dimensional lists don't even exist in Axe, this is a bit of a stretch. Implementing such constructs (properly) would really require a type system, which Axe doesn't have. Such features are the kind of things I'd imagine in an Axe 2.0, but I don't see that becoming reality right now.

These are just some ideas I don't know how may are possible or feasable.

I'm grateful for all your suggestions. It's nice to see that some people are still interested in making Axe better. :)

Offline E37

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 306
  • Rating: +21/-0
  • Trial and error is the best teacher
    • View Profile
Re: Features Wishlist
« Reply #3456 on: January 18, 2016, 11:03:31 am »
As for making axe better, Is there anything else I can do?
I'm still around... kind of.

Offline Haobo

  • LV2 Member (Next: 40)
  • **
  • Posts: 27
  • Rating: +4/-0
    • View Profile
Re: Features Wishlist
« Reply #3457 on: January 22, 2016, 03:31:17 pm »
Some more things that might help with dealing with these.
The option to run the program right after compile whithout having to go back to the home screen would be nice.
Having Axe back up all files compiled (if multiple programs are included with the prgmNAME command) could be helpful.
If you attempt to run a source code file it could compile then run.
These were already implemented by zstart. It has a bunch of shortcut keys to archive every program, edit programs from archive and exit without saving, and running the program right after compiling. It will also auto archive files that you compile in axe so that data isn't lost. Backing up files isn't really necessary if you can edit from archive, and axe already supports compiling from archive.


Pause until something happens, like pause until the enter key is pressed.

Not sure if this helps, but the getKey^^r function works pretty well for a temporary pause, until a button is pushed. For more specific inputs, you should probably make a function yourself for that.

Really recommend zstart if you are into programming on the actual calculator. It also allows you to jump to Lbl's throughout the program quickly in case the program is huge and the shortcut keys help a lot.
Projects:
Star Cats
Five Nights at Freddy's
Phoenix Wright

Offline E37

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 306
  • Rating: +21/-0
  • Trial and error is the best teacher
    • View Profile
Re: Features Wishlist
« Reply #3458 on: January 22, 2016, 04:05:27 pm »
I already have zStart, I don't like the auto archive function though.
I'm still around... kind of.

Offline Haobo

  • LV2 Member (Next: 40)
  • **
  • Posts: 27
  • Rating: +4/-0
    • View Profile
Re: Features Wishlist
« Reply #3459 on: January 24, 2016, 03:28:19 am »
Don't really know why you would not archive it. Saving programs might be a bit longer, but it's still a lot better than duplicating the program in memory, which is what the backup does. Archiving just gives it a double failsafe. Plus, you can use it as a temporary version control (though with only 2 versions) since axe doesn't backup archived programs.
Projects:
Star Cats
Five Nights at Freddy's
Phoenix Wright

Offline E37

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 306
  • Rating: +21/-0
  • Trial and error is the best teacher
    • View Profile
Re: Features Wishlist
« Reply #3460 on: January 24, 2016, 11:23:05 am »
I make lots of test programs and like to use the on + trace/zoom to run them. I don't need to them to be archived.
I guess I am probably overly worried about long-term damage on my archive.
I'm still around... kind of.

Offline E37

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 306
  • Rating: +21/-0
  • Trial and error is the best teacher
    • View Profile
Re: Features Wishlist
« Reply #3461 on: April 18, 2016, 06:06:09 pm »
I have a couple more ideas!
The a function like the += command in Java would be really cool! (5 +-> x instead of x+5->x)
Setting to zoom compile by default
The ability to treat lists like matrices (like # -> {L1}{row}{col} instead of # -> {rows # col + row + L1}) would save SO many headaches
Again, I don't know how easy to add any of these are. (but the matrices one would be really nice)
I'm still around... kind of.

Offline neuronix

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 108
  • Rating: +0/-0
    • View Profile
Re: Features Wishlist
« Reply #3462 on: June 30, 2016, 12:04:54 pm »
Add a line per line debug function :D

Offline E37

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 306
  • Rating: +21/-0
  • Trial and error is the best teacher
    • View Profile
Re: Features Wishlist
« Reply #3463 on: June 30, 2016, 07:00:58 pm »
Add a line per line debug function :D
While that would be awesome, I don't think that would be very practical on calc.
If you want a debugger your best shot is wabbitemu.
I'm still around... kind of.

Offline neuronix

  • LV4 Regular (Next: 200)
  • ****
  • Posts: 108
  • Rating: +0/-0
    • View Profile
Re: Features Wishlist
« Reply #3464 on: July 01, 2016, 09:18:51 am »
When I say a debugger line per line, I would say when I compile, I try to compile line per line and disp the error message for the line ;)