Omnimaga
Omnimaga => Completed => Our Projects => Grammer => Topic started by: Xeda112358 on April 26, 2012, 04:52:00 pm
-
As I mentioned int he Grammer 2 topic, I should be starting Grammer 3 in about two weeks if I am on schedule (1 year after Grammer 1 was started). Because this is the time that I will be without internet, if you have any ideas, post them here, I will make a copy of it, and I will reference it while I am working on the program. In the plans for Grammer 3 since the start:
It will be a two page app
It will have a legacy mode for older Grammer programs
It will have a built in program editor
It will allow for custom command sets (up to 16 packages that contain their own functions).
- This will mean you can have a floating point math command set, linking command set, and others
- I might bring this down to 8 possible sets at a time
- These will be defined at the beginning
Source code will be "tokenised" like on the TI-89. This will help speed it up massively.
There will be specific variable types like sprites, fonts, and strings
I am thinking of adding in standard 32-bit math.
4-level grayscale and 3-level gray
More tile map options
Proper sprite clipping (I've already got the code planned)
If you guys can think of any good ideas, please post. For the editor, what would make things easier? I will be writing a menu system, so I will probably include customisable menus, quick keys, and other things. Maybe I should make a search function? Search and replace? Since Grammer will have so much control, errors will be completely handled by Grammer, so if you press ON for example, Grammer will take it to the Grammer editor, not the program editor.
-
2 page App ? :(
Could Grammer 3 load Omnicalc fonts, for example ?
-
2 page App ? :(
It will have to be D: (Omnicalc is two pages ^^')
Could Grammer 3 load Omnicalc fonts, for example ?
Yes, I can definitely add that. Do you mean load them for use in the Grammer program or in the OS?
(If it is loading them for the Grammer program, I can actually add that right now to Grammer 2).
-
for use in the Grammer program or in the OS?
both, both... It was just an idea, I don't particulary need it. I know that Output allow you to load a font set, but, I don't know if Omnicalc font sets are compatible with Grammer font sets.
Other idea: I particulary love Celtic III's fonctions to manage groups. Do you know about ?
Make a list of the files in the group, in which order they are, possibility to ungroup just one of them...
And another idea take to Celtic: Access to Temp progs... (We can do an equivalent with actual Grammer commands, but if you want...)
-
Hmm, that is a good idea to be able to at least unload certain variables from a group (I've been working on the code to do that, actually, but for another project. I can add it to Grammer, too :D)
Also, Grammer has access to TempVars. You can even copy a program from archive to a temp var and run it as a Grammer program, currently:
solve(0,"EPROG","VTemp1→A
prgmA
--OR--
prgmsolve(0,"EPROG","VTemp1
Also, I am almost finished adding in Omnicalc fonts :)
-
I never knew that I could do the second option O.o
-
It's all just pointers, whether they are passed through Ans or through vars :)
-
Idea for grammer 3: A good readme :P
-
Idea for grammer 3: A good readme :P
Coming soon :) in French.
-
Idea for grammer 3: A good readme :P
Coming soon :) in French.
D: Why not in english? :(
-
Because I'm french, so I write it in french. :P
I could translate, maybe. If I have time.
-
That would be cool :)
-
Yes, for Grammer 3, I will make sure to have a good readme :) (That is a good idea)
EDIT: Yeong asked about adding a menu hook in Grammer 3 and that reminded me about some of the other menu features that I think would be awesome.
Since Grammer 3 won't be using the OS menu system, I will definitely be adding a way to make a customisable MenuKey that works like my MenuKeyHook. I will also make it easy for the user to add in extra, customisable menus, too.
Also, since I plan to have custom command sets, I will probably leave the F1 to F4 keys as changing menus depending on what command sets you have loaded. F5 will probably be the custom menu.
-
2 page App ? :(
It will have to be D: (Omnicalc is two pages ^^')
Could Grammer 3 load Omnicalc fonts, for example ?
Yes, I can definitely add that. Do you mean load them for use in the Grammer program or in the OS?
(If it is loading them for the Grammer program, I can actually add that right now to Grammer 2).
Omnicalc is two pages? ??? I thought it was one. Although I am fine if it's two pages since it has so many features.
ANyway good luck on Grammer 3 Xeda :)
-
Oh, you are right, it is only one page o_O
-
Idea for grammer 3: A good readme :P
Coming soon :) in French.
D: Why not in english? :(
Because I'm working on that one. :P
-
Idea for grammer 3: A good readme :P
Coming soon :) in French.
D: Why not in english? :(
Because I'm working on that one. :P
Haha, cool, forgot it :P
-
It's ok, since it haven't got any progress for a while. :P
-
i had an interessant idea:
Could it be possible to make big conditions for graphics, as an alternative to pixeltest ?
For example:
:If Line('2,2,30,29): and B=6
:stuff
Do you think it's possible ? Grammer would innovate, with Pixel-tests, Line-tests, Circle-tests, maybe Text-tests :D !
If it is, can I suggest one level more harder again: A sprite-test detection ?
-
Do you think it's possible ? Grammer would innovate, with Pixel-tests, Line-tests, Circle-tests, maybe Text-tests :D !
If it is, can I suggest one level more harder again: A sprite-test detection ?
In fact, I think the sprite test detection would be easier to do than the other detection o.o
For exemple, in Axe, you have Pt-Get (which "extracts a sprite from a buffer", if I can say so) and Equ>String (which compares two strings), and a good use of a combination of both can give you your sprite test ;)
-
A sprite-test detection ?
A text test is a sprite row test so one implies the other. ;)
Edit : Ninja'd.
-
Actually, I already have the code for pixel-testing along lines, circles, sprites, and rectangles (but pixel testing rectangular regions already exists in Grammer). In fact, here is an example where I used my sprite pixel testing:
(http://img.removedfromgame.com/imgs/FallDwnEx0.gif)
It doesn't return how many pixels there are, though, it only checks if there are any pixels. (so it returns 1 or 0). As a note, that is not a Grammer program or a Grammer 3 program :P
-
A sprite-test detection ?
A text test is a sprite row test so one implies the other. ;)
True story bro. But that doesn't work for the line and the circle. This is why I really think that sprite test detection is much more likely to happen than arbitrary geometry forms detection (not sure about the meaning of my sentence).
edit nevermind my post, I got ninja'd by Xeda whose answer is surely more accurate
-
This is why I really think that sprite test detection is much more likely to happen than arbitrary geometry forms detection (not sure about the meaning of my sentence).
Actually, at the assembly level, it is very easy to pixel test on lines or circles (and by very easy, I mean it is as easy as drawing the shape, but a little faster in most cases).
-
I didn't speak about geometrical shapes. ;) Only text and sprites.
Edit : Ninja'd twice in a row. D:
-
The grammer test command for a recangle is "true" if 1 pixel is on...
Is that possible to make it "true" only if all the pixels in the rectangle are on ?
And, for the line, I think I can use a rectangle with a width of 1.
-
If you know the width and height of the rectangle, you can see if W*H:=Line(X,Y,H,W,14
-
Exact. Very well, thanks.
-
Perhaps Grammer 3 should support multi-character variable names.
-
Perhaps Grammer 3 should support multi-character variable names.
You can already do this. kinda.
-
With Grammer currently you kind of can. With the organisation of Grammer 3, you will be able to use variables that are named, but when the program is precompiled, it will convert variable names to two byte addresses. (It will still keep track of the names, though). I am still trying to figure out a good way to handle string concatenation and external variables.
-
I think you should give Grammer a different syntax(keep backwards compatibility, though) Some of it is just so confusing(Y before X?! WTF!?) Another idea is to add "header files" like in higher level languages so that you can have whole bunches of routines for complex stuff already set out for you(like collision checking, for example). Some of these might be dumb because i'm kind of a noob at grammer :P
-
Y before X is because in TI-BASIC many commands are that way too. Grammer was made specifically to get TI-83+ BASIC coders used really fast to it.
-
Y before X is because in TI-BASIC many commands are that way too. Grammer was made specifically to get TI-83+ BASIC coders used really fast to it.
Yes, precisely, like with the Pixel commands and Text( in TI-BASIC.
And I am not sure I understand header files, but does this sound useful:
I have planned for Grammer 3 to keep the last 16 tokens for an extended command set. In TI-BASIC, there are a handful of two-byte tokens which is basically what this is. The difference, though, is that you can load different command sets into your program. For example, if a command set is made for 3D rendering, called 3DRender, you might do something like:
Ext0 3DRender
I haven't quite gotten down how I want to incorporate this code-wise. I will want to let the user install command sets as either appvars or apps, but I will have to have some format to tell Grammer what arguments each command can take x.x Grammer also has some pretty high-level variable structures like n-dimensional arrays, actual string support, sprites, bit-maps, integer math and there are still a few more types that I am working on like Floating-Point and fixed-point math. The editor is just a real pain, still x.x The format that I currently have, though, makes it easy to jump to sections of code and edit things like sprites in-line :)
-
Oh... I guess I've been doing BASIC coords wrong the whole time >.< But a header file is pretty much just like an inc file in asm, or a .h file in C and C++, they define lots of routines and constants and whatnot that you can use with nothing but a simple #include or import statement. Floating point math might be helpful, but it also might muddle the number system up a bit. Maybe you could have a special "float" datatype, like in C and C++. The editor sounds really cool, though, I hate having to jump around between DCS7 edit mode and Grammer app :P
-
Oh, yes, that might be useful (the header thing). As well, floating point numbers are a different type from integers. Integers also have signed/unsigned, and 8,16,32, and arbitrary sizes.
-
What about adding fixed-point math?
-
ben_g: Look up 3 posts. ;)
-
Oops. I only quickly read trough the previous posts. I must have missed it.
-
Extensions for 3D and stuff would be nice, although I wonder what would be the format. Would they be appvars? Because some people might confuse them with the game program files if they're also programs and delete them if they decide to delete the game. :P
-
I think that appvars are the best file type for extensions. And about the format, I can't think of another one than the format used in Axe's axioms. It's so practical.
-
Yeah, that is what I am worried about. Basically, for the extensions, the appvar/app/program would need to contain all of the code for handling certain commands. I am pretty sure that I have gotten a good format for calling the extended commands, the difficulty is in compiling the programs that use extended commands. Actually, this is the same problem for built in commands, too XD. I could manually create a Grammer 3 program at the moment, but having a compiler would be much less tedious. Basically, for something like the Rect() command, this:
Rect(X,Y,8,8,2)
Needs to be converted to:
20 ;20h = Rectangle command
10 0000 ;10h says it is a 1-byte integer, 0000 is the compiled offset into the integer table
1F ;ends the argument. Think of this like a comma.
10 0100 ;another 1-byte integer
1F
08
1F
08
1F
02
1E ;end the command. Basically an ending parentheses
So I know what it is supposed to compile to, it is just that I need to work up the motivation to create the compiler x.x I actually started writing the compiler a few months ago in Grammer 2 code after I added in the new Input command with syntax highlighting.
-
I think that a 2-bytes command ID should be better, since with extensions and all the number of commands can easily go more than 255 (how do you say that correctly English ? :/)
-
yes, I am sure it will and that is what the extended commands are (multi-byte tokens, basically). So for example:
F800 ;Command 0 of one of the extended token sets
I was also trying to figure out a good way of allowing the extended sets to have extended tokens just in case, but I don't think I will need to do that (will we really need 3-byte tokens? :P)
-
Just out of curiosity, what's the newest version of Grammer available for download? (I have 2.01.05.12) Also, I found a bug for that version: when you are in the screen where you choose the program, if you press [ON], after you say quit to the error, the homescreen is filled with some junk. Probably not an important bug, but I thought you might want to know regardless.
-
3-bytes tokens are really a PITA to work with, and you won't be able to use the token hook with them.
Or maybe ... Let's have an example : say that the first token (which should be a 2-bytes one because rarely used) of a pack is det(. You would apply a token hook on det( to make it look like (for example, with a 3D renderer pack) "3Drender_". Then you could apply a token hook on other tokens which will be the actual commands. So for example the command det(Boxplot which is the first command of the command pack, would look like 3Drender_tri( with a token hook and F005 as hex (since det( is the prefix of all of the commands of the first command pack).
So with all of this, we can define the structure of a command pack :.dw prefixToken
.dw command1token
; define everything related to a command
.dw command2token
...
.dw $4242 ; magic number which ends the command definition
; token hook
Something you can do with it is dynamically assignating the F0 to FF token to the corresponding prefix. It would allow the use of multiple command packs without any problem.
What do you think of it ?
-
@ghest: Coincidentally, I just found that bug for the first time yesterday, too o.o (I was working on another project). I am not sure what would cause it, but I will try to figure it out. You have the latest complete release (the one that comes with a readme), but this is the latest update: http://ourl.ca/13558/336252
I am not sure if I broke anything in that version, though :/
@Matrefeytontias: Grammer 3 won't be using the OS tokens or the OS program editor, so I won't need to worry about that. I am working on creating a custom program editor and token set. I am also trying to keep it customisable, that way it can be easily ported as a BASIC program editor, Axe, or Assembly, but that is really difficult x.x
-
i'm keep forgetting if Grammer had a and/or/xor logic for recalling picture.
-
Oh, yeah, grammer 3 will have tileapper and sprites, right?
And taking use of static poitners to safe ram areas as axe has would be awesome too.
Mhmm, what else......maybe a real and/or (so we don't need to use * and + anymore)
-
Yes, RecallPic has those abilities, currently and that will definitely be still around for Grammer 3. I might have separate tokens like xorSprite(), though.
EDIT: @Sorunome: Grammer 3 has a variable type for sprites, so definitely. Also, I like the idea of having static pointers and about the logic, I should do that for sure. Maybe I will have bitand, bitor, and bitxor instead. Currently, you no longer need to use + or *, as long as your tests produce a 1 or 0. For example, this works as you would expect it:
If A=3: and B=7
You just need a colon between tests.
-
Is colon still new line?
-
It is kind of like a newline, but not really. You can use a colon in conditions for If, While, and Repeat, among other things. A colon just separates chunks of math.
-
What about adding structured variables and more, objects with methods like in Java ? Maybe I'm dreaming.
-
I am not familiar with Java or the terms "structured variables" and "objects with methods." However, maybe this will answer your question:
In Grammer 3, there will be a few variable types such as:
Sprites - These get stored at the end of the file and have a size automatically associated with them. This means that the sprite command will work like this: Sprite(ptr,Y,X,Buffer)
Strings - These will have two forms, ASCII or Tokens.
Arrays - There will be a few forms such as fixed size arrays or the more flexible variable arrays (each element can be any variable type, including strings, numbers, sprites, or other arrays)
Integers - There will be signed, unsigned, and different sizes. Currently it only has 8-bit and 16-bit unsigned.
Fixed Point - These will be used for extra precision and will allow you to store numbers such as 2.3125
The actual details are really cool and I started working on the program editor earlier today. For example, the attached image (I made it in paint; it is not real) shows how sprites will be in-line and you will be able to directly edit them. But the really cool part is that the two sprites are the same sprite. Editing one automatically edits the other and any other instances of the sprite in the program. Here is how it works:
There will be local and global variables. Local variables will have a bunch of data stored about them within the program such as their name and the actual data. Local variables include labels, too. Each variable will have a 2-byte ID. When the editor reads the bytes, it will display the name of the variable if it has one. If it does not have a name, the contents of the variable are shown instead. In the editor, if you have highlighted the variable name/data, you will be able to edit the variable data (the program editor will know which var to edit based on the ID). So this means you can edit the name of the variable and all instances in the program will be changed automatically since it is only referred to by an ID. This also means if you use the same string multiple times, changing it in one place changes it everywhere else (as an example).
When running the program, if it is already in RAM, it will just be run directly. If the program is in archive, only the essential data will be copied to RAM. I am still trying to figure out what counts as 'Essential', though. Obviously the variable/label names wouldn't need to be copied since that is just for the editor. But as long as everything else is static data, I might be able to have Grammer keep the whole program in archive.
Oh, also, subroutines are a type of variable. For example, "Repeat " won't be a real command. Internally, it will just be stored as:
Lbl Repeat
Call Subroutine
If <condition>
Goto Repeat
But in the editor, it will look like a Repeat loop.
-
I really like the ideas you have for the editor. That sounds awesome! :D
-
I think automatically changing the variable names is dangerous--it's super helpful to do that, but sometimes I just want to change the name one time, and not the rest. There should be a way to refactor it, but doing it automatically could lead to frustration.
-
Hmm, I was thinking about that issue. I was thinking of making it easy for the user to disassociate a particular instance from the rest with maybe a quick key or menu.
And thanks, Art_of_Camelot!
-
Wow, displaying the sprites inline in the editor looks awesome O.O
-
Wow, the editor is EXACTLY as I dreamt it to be ! The sprites, the edition of variables' names... !!! :o
For the Repeat command, it could be an bad point though, because the speed would decrease doing so.
I hope we'll be able to "compile" a program in order to delete variables' names so that the program has a smaller size. And maybe could you do a 1-page application which doesn't have the editor but that can run Grammer programs ? Because 2 pages are a lot for persons who just want to run the programs...
I assume that bigger sprites will be given a name in order not to take all the screen's place. :p
I hope that the text "Program : TEST" will be removed to have one more code line.
Grammer 3 promises to be a really really good app. Thank's !
-
Wow, the editor is EXACTLY as I dreamt it to be ! The sprites, the edition of variables' names... !!! :o
I am glad you like the look ^_^ I am about to start coding some more, so hopefully I can make it work the way I envision it!
For the Repeat command, it could be an bad point though, because the speed would decrease doing so.
It would actually still be fast since this is how Repeat loops are typically handled anyways. I am doing it this way because it will help to prevent stack overflow issues. Math might change, too, by the way. I am still working out how I want to efficiently handle math. I will probably attempt Order of Operations so you can do something like 3+6*(a+b4) like you would in BASIC.
I hope we'll be able to "compile" a program in order to delete variables' names so that the program has a smaller size.
This is an excellent idea and I was thinking about doing that. The way it is currently set up, it is very easy to separate the names from the program which could save a bunch of memory. As well, a few other tokens can be removed to save a byte here and there (and the source will still be able to be edited).
And maybe could you do a 1-page application which doesn't have the editor but that can run Grammer programs ? Because 2 pages are a lot for persons who just want to run the programs...
I was thinking about this and I at first thought I might be able to make one app for the editor, and one app to run the program. However, I was going to add a lot more commands to Grammer 3, so the parser would still need 2-pages :/ Then you would have a 2-page app for running Grammer programs and a 1-page app for editing them. Instead, I will try to make it just 1 app that is 2-pages.
I assume that bigger sprites will be given a name in order not to take all the screen's place. :p
If the sprite is too big, I will have it display maybe a 16x16 portion and if the user wants to use edit it, a special editor will open.
I hope that the text "Program : TEST" will be removed to have one more code line.
That is a good idea. I will probably still stick menu options on the bottom row, though :P For example, 5 options for F1~F5:
[Char][Set ][Calc][Copy][Exit]
Char will let you access the character set (so the ASCII)
Set will allow you to load an external command set. So if anybody makes a Physics package, for example, you can load the Physics commands and view the token set for that.
Calc Will open up a calculator window so that you can run a simple computation like 3*47+6(7*8) and paste the result into your program.
Copy Will be for copy/paste stuff.
Grammer 3 promises to be a really really good app. Thank's !
I hope I actually finish it! I have been planning for over two years now, so hopefully you will get a chance to finally use it!
-
It would actually still be fast since this is how Repeat loops are typically handled anyways. I am doing it this way because it will help to prevent stack overflow issues. Math might change, too, by the way. I am still working out how I want to efficiently handle math. I will probably attempt Order of Operations so you can do something like 3+6*(a+b4) like you would in BASIC.
Cool ! Will the app support variables' declaration with the type ? And what about local variables ? Will we be able to do recursive functions ?
I was thinking about this and I at first thought I might be able to make one app for the editor, and one app to run the program. However, I was going to add a lot more commands to Grammer 3, so the parser would still need 2-pages :/ Then you would have a 2-page app for running Grammer programs and a 1-page app for editing them. Instead, I will try to make it just 1 app that is 2-pages.
Why not put the most needed functions in the 1-page app parser, and then put other functions into several appvars which would be used like the DLL ? Programs needing such a appvar would require it, and even though the user would use all the functions, the final size woudn't be 16 kilo bytes. Of course, updating would be more difficult... Finally, a 2-page app isn't so big when be think about Omnicalc and so. And the containing of an editor could appeal users of programs and give them curiosity to try to do something. Will you introduce hooks like the OS to customize the editor, like adding tutorials as you did ?
If the sprite is too big, I will have it display maybe a 16x16 portion and if the user wants to use edit it, a special editor will open.
It's not really a good idea to my mind, because we couldn't see the difference between pictures which don't have any pixel on on the board up left.
Will you add the support of tilemaps and an editor of tilemaps ? Will you add a basic pictures compression ? What about gray-scale sprites ?
That is a good idea. I will probably still stick menu options on the bottom row, though :P For example, 5 options for F1~F5:
Please don't, it is usefull the first 5 minutes, but then we know the keys and don't need their action's description to be shown anymore, and a line of code is removed.
I hope I actually finish it! I have been planning for over two years now, so hopefully you will get a chance to finally use it!
Yes, and I've been waiting for those two years ! And hope you'll finally do it ! ;D
NB : know that you're doing a 2-pages app, will you be able to add a command to parse pieces of code as someone proposed it ? But after having finally done this version 3 for sure.
-
Cool ! Will the app support variables' declaration with the type ? And what about local variables ? Will we be able to do recursive functions ?
Well, for example, if you start typing with a ", the parser automatically pastes another " and an un-named string variable will be created. You can go into the vars menu (or press a specific button) to name the string. For other variable types, you will have to create them in the variable menu. For example, sprites will need a width and height associated with them, so you will need to input that.
Local variables are going to be just variables that are stored with the file, so it isn't like real "local variables." Instead, you can pass arguments to other programs, you can define a global variable.
For recursion, you will probably want to use the stack functions which will allow you to push/pop variables.
Why not put the most needed functions in the 1-page app parser, and then put other functions into several appvars which would be used like the DLL ? Programs needing such a appvar would require it, and even though the user would use all the functions, the final size woudn't be 16 kilo bytes. Of course, updating would be more difficult...
I could possibly do that, but it is a lot more difficult to read and execute code from an appvar. As well, it is slower, since I would have to locate the appvar, find the specific code, copy it to RAM, then run it. (As opposed to 'find the code, run it').
Finally, a 2-page app isn't so big when be think about Omnicalc and so. And the containing of an editor could appeal users of programs and give them curiosity to try to do something. Will you introduce hooks like the OS to customize the editor, like adding tutorials as you did ?
Hooks are definitely a planned feature. There will not be a parser hook since you will be able to load custom command sets, but getkey hooks, font hooks, and token hooks would be a great idea. Custom fontsets will be available, as well as token sets, but this might be useful for different languages.
It's not really a good idea to my mind, because we couldn't see the difference between pictures which don't have any pixel on on the board up left.
Hmm, maybe I should display the whole thing, then? Either way, you would still be able to select it to open up a larger view.
Will you add the support of tilemaps and an editor of tilemaps ? Will you add a basic pictures compression ? What about gray-scale sprites ?
Tilemaps will be supported and my hope is to have a similar editor. There will definitely be compression routines for pictures and text, and I have been trying to figure out how the grayscale editor will work (for sprite editing), but there will still be grayscale (at least 3 and 4 level).
Please don't, it is usefull the first 5 minutes, but then we know the keys and don't need their action's description to be shown anymore, and a line of code is removed.
Okay, I will just leave that to the readme, then :)
Yes, and I've been waiting for those two years ! And hope you'll finally do it ! ;D
Me, too :P
NB : know that you're doing a 2-pages app, will you be able to add a command to parse pieces of code as someone proposed it ? But after having finally done this version 3 for sure.
I am not sure what you mean, sorry .__.
*Edit AOC* Fixed a typo. ;)
-
Hmm, maybe I should display the whole thing, then? Either way, you would still be able to select it to open up a larger view.
If we give a name for the variable, does the name replace the display of the picture ?
NB : know that you're doing a 2-pages app, will you be able to add a command to parse pieces of code as someone proposed it ? But after having finally done this version 3 for sure.
I am not sure what you mean, sorry .__.
Well, I was speaking about that : http://ourl.ca/14658/346271 (http://ourl.ca/14658/346271)
PS : If I make any mistake, I would enjoy to be corrected so that I improve my language. :)
-
Oh, the whole code is being preparsed. Are you saying, for example, to compile some parts of code directly to assembly?
-
Yes. A command that compiles a part of Grammer code dynamically, and that does so that this part be compiled in the current context. For example : if a variable has a specific value, the code using it could be parsed as if it was a constant : some operations could be calculated before the parsing, and the code would be really fast in the context. It could be usefull when there's short loops (-> fast parsing) but with lots of iterations (-> lot of time preserved). Like in Java, but asking it manually.
But don't take consideration to this really hard point, it is much less important than the other ones.
-
What would be really cool is some kind of function to help you to create your own libraries. It's probably a dumb idea, but it seemed OK... ::)
-
As it currently is, just having labels and variables pre-parsed saves a lot of time and having numbers pre-parsed saves a lot more time. For example, Grammer 2 takes nearly 70 t-states for each digit extra in a number, but Grammer 3 takes 13 t-states for every 8 bits. For comparison, 65535 takes about 350 t-states for Grammer 2 to read and convert, and only 26 t-states for Grammer 3. While it still won't be as fast as Axe, it will still be faster than Grammer 2.
The other thing that I am now trying to figure out is how to make math much faster, but I always worry about that.
I have one more random thing before I finish this post. I just put together a quick example program in Grammer 3 and the size of the code and variables together is 80 bytes. The equivalent in Grammer 2 is 86 bytes (not including the header), so there is some small size savings there. I might have an active screenshot in the next few days if I don't get distracted again. I got a book last night and read it and I got distracted by lots of math stuff >.>
EDIT:
@codebender: Well, you will be able to write and define functions in Grammer code :) However, command set extensions will need to be written in assembly.
EDIT2:
Well, I threw together a quick example of a Grammer 2 program and a Grammer 3 programand you can't see much of a difference (though it is approximately 20% faster). I am hoping that when I optimise the code for the new syntax, it will get a little more speed. Also, I have math reading left to right, now that I don't have to worry about the issues that math had in Grammer 2. This means that math should be faster and use less stack stuff than Grammer 2. I also still have to update the sprite drawing routine to use the better one in BatLib (which draws large sprites, clipped, and possibly faster).
-
Very good to see progress :)
-
Are you also thinking about making math follow the order of operations instead of evaluating left to right? Doing so shouldn't be hard, especially for you.
-
I am thinking really hard about how to handle math. I can definitely make it handle order of operations, but it would be a little slower.
-
I am thinking really hard about how to handle math. I can definitely make it handle order of operations, but it would be a little slower.
A little slower ? Why not when parsing put the operations to the usual order ? Then it would be the same speed.
-
I am thinking really hard about how to handle math. I can definitely make it handle order of operations, but it would be a little slower.
A little slower ? Why not when parsing put the operations to the usual order ? Then it would be the same speed.
I was thinking about converting the math into postfix notation when parsing to bytecode.
-
maybe just some order of operations like axe or like current grammer2? You can still do a lot with it as long as paranthesis work :)
-
If I can figure out a way to convert a formula in order-of-operastions to a more optimised syntax (and back again), then I would prefer to do that. I think I will have to look into RPN for ideas. For example, in Grammer 2 it is possible to mentally convert a formula to OOP, but I have to think of a way to program it. As an example:
3*4+A:/6-B
is equivalent to:
3(4+A)/(6-B)
-
If I had to choose, I'd choose either "right to left" or "left to right" since it allows more optimizations from the coder and is easier to code for you :P
Left to right seems to me the best choice since it even allows optimization from one line to the other, like in Axe ;)
Now, if you prefer adding support for the usual order of operations, that is not a problem, but please just don't come up with a new order where the addition comes before the multiplication (like 3*4+1 == 3*(4+1)) :P
-
Why not adding a way to contol the registers, it would be incredibly faster I think! But it shouldn't be an obligation for the user(maybe a specific Token?)
-
Why not adding a way to contol the registers, it would be incredibly faster I think! But it shouldn't be an obligation for the user(maybe a specific Token?)
It wouldn't be faster since it is an interpreted language. If you wanted to have that, the app would have to manage virtual registers since the app already uses them. Like the Calcsys' console does int fact.
-
Why not adding a way to contol the registers, it would be incredibly faster I think! But it shouldn't be an obligation for the user(maybe a specific Token?)
It wouldn't be faster since it is an interpreted language. If you wanted to have that, the app would have to manage virtual registers since the app already uses them. Like the Calcsys' console does int fact.
This is precisely the reason ^ I made Jade for that ;)
-
But with the compiled version, are the registers free?
-
No, the registers aren't free since it will still be interpreted. The compiling simply precomputes things that can be, since that would save time. However, one of the features I forgot about was adding support for in-line assembly, and not just hex codes. For example, you might have a block that looks like:
Z80Asm
ld hl,plotSScreen
ld (hl),0
ld bc,767
ld de,plotSScreen+1
ldir
I do actually have a compiler started for this.
-
Wow, so it would be a Mimas-Grammer app ? :o
-
Kind of :) My hope for the program editor is that it can be used for other languages such as BASIC, Assembly, Axe, and Grammer.
-
That'd be awesome. *.*
-
That is a nice idea :D
Also a custom program editor would be really nice if there was ever a CSE version of Grammer, because scrolling is atrociously slow.
-
For the purpose of testing I started the BASIC program editor. As it currently is, I have all of the 1-byte tokens added and some 2-byte tokens. I tried not to change anything except to fix up some issues with the BASIC tokens. In particular, pic variables, matrix, Str, GDB, and list variables that are hacked now have actual names. The way I designed the token system, it is possible to use code in place of a token string, so they do not have huge LUTs. Instead, just a simple code that handles each of those. So for example, the 255th hacked string is now displayed as Str255 instead of a question mark. I also made it pretty easy to handle multi-byte tokens, so I plan to add in tokens for Axe, Grammer 2, BatLib, Omnicalc, Celtic 3, DoorsCS7, and xLib commands.
(I should note that I decided to make the Editor app separate from the Grammer 3 app.)
The Grammer 3 editor will be a bit tough to create, to say the least. The BASIC editor is not taking advantage of many of the features I have already programmed into the editor, but the Grammer 3 editor will hopefully be packed with features.
I hope I didn't get any hopes up, though, because the editor doesn't do any editing yet. You still cannot choose things like the program to open, the font to use, the token set to use, the screen size, or wordwrap modes, even though those are all programmed in.
-
wow, that's sounding like a bunch of awesome features!
Can't wait till it's done :)
-
Looks good so far. Will the editor supports going to the top/bottom of the code like Casio calcs and will we be able to access tokens as easily as via the TI-OS?
-
saying that, maybe label jumping just as zstart does with on+vars would be cool :D
-
Auto indentation. :D
-
Label jumping is the plan, as well as jumping from the top to the bottom. Last night in HCWP, I was fairly productive and tested a bunch of things including the font and making certain tokens invisible (like Then and End tokens). I also adjusted the indent to be more logical. Today I want to try to make some "token hooks" for the other languages and try to get it so that you can move through the source and possibly edit code.
For menus and otherwise accessing tokens, I hope to make it similar to TI-BASIC, but with a few changes. So you can still access the drawing commands by pressing [2nd][prgm], and the order will be basically the same. However, I might add in some pages to the math commands, and for token sets like those for Celtic 3, Omnicalc, and others, more menus will have to be placed somewhere. As well, I plan to have a more organised catalog.
EDIT: Forgot the screeny with invisible tokens.
-
Would invisible End/then tokens pose problems if someone wants to delete them? I mean that the person might often try to delete them, but place the cursor at the wrong position then delete his previous code instead.
Regarding not using two Thens or too many ends by mistake due to forgetting that you already added them, I guess automated indentation would be solving that. :P
I forgot about the following, but is it possible to choose between small and large fonts?
-
I wouldn't put the end/then tokens invisible...........and i like the small font A LOT more. but yeah, great job! :D
-
Yes, the user will be able to choose the font and it currently works with custom fonts that are in RAM. The invisible tokens thing was just a test I did last night on HCWP and it felt like Python code. I think I will leave that as an optional token hook because it does allow more code to be shown. Speaking of token hooks, I modified the code to better support token hooks and I added in the Celtic 3/PicArc tokens. I am now working on xLib and Omnicalc tokens, but I have found that I cannot find a list of the Omnicalc real() values anywhere :/ I will have to look at each of them myself, then.
The screenie is an example of how the token hook can modify the token set for Celtic 3, PicArc and xLib commands. It also shows how hacked matrices are named.
EDIT: Is it me, or is that large font annoying?
-
They are in the Omnicalc readme: https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CC8QFjAA&url=http%3A%2F%2Fwww.omnimaga.org%2Findex.php%3Faction%3Ddlattach%3Btopic%3D11145.0%3Battach%3D10138&ei=MFPDUd_BKOqF4gTE-IDgDw&usg=AFQjCNH_0vCkoKVimvM5L2Cw-KCTTJaplQ&sig2=1OGpbjk2CJs6IGq1yST50w&bvm=bv.48175248,d.bGE
And looking nice :D
-
(I should note that I decided to make the Editor app separate from the Grammer 3 app.)
The project of an editor is gaining the upper hand on Grammer3 then? Too bad. More, if you'll still make Grammer3, users will need 3 pages of apps : 2 for Grammer, 1 for the editor.
Last night in HCWP, I was fairly productive and tested a bunch of things including the font and making certain tokens invisible (like Then and End tokens).
To my mind, not really a good idea to do like Python. Basic language got a low level of interpretation which allows to do weird stuffs like multi-instructions after an If without Then, conditional enters in a loop (http://www.siteduzero.com/informatique/tutoriels/apprenez-a-programmer-en-ti-basic/la-magie-de-delvar), routines in the same program (http://www.siteduzero.com/informatique/tutoriels/apprenez-a-programmer-en-ti-basic/un-end-qui-se-termine-ailleurs) etc. But yes, you could make it optional.
-
Have you considered adding code folding to the editor?
-
The editor already takes over 7000 bytes of memory. I also need to get the editor working for Grammer 3 programs before I can really progress with making the interpreter. If I can, I will include the editor with Grammer 3 (if they fit). They do share a bunch of the same code, so that should make it easier.
EDIT: @ben_g: What do you mean by code folding? Do you mean like hiding blocks of code unless the user clicks on it to expand it? If so, then yes, but it won't be easy to implement for the BASIC editor.
-
The editor already takes over 7000 bytes of memory. I also need to get the editor working for Grammer 3 programs before I can really progress with making the interpreter. If I can, I will include the editor with Grammer 3 (if they fit). They do share a bunch of the same code, so that should make it easier.
EDIT: @ben_g: What do you mean by code folding? Do you mean like hiding blocks of code unless the user clicks on it to expand it? If so, then yes, but it won't be easy to implement for the BASIC editor.
Yes, hiding blocks of code like the inside of functions or loop, so you will for example only see:
[+]function doSomething(argument) {...}
And if the user presses the - icon, it should show everything inside the function. It can be really usefull if you only use a single source file, because with code folding, you have to scroll trough huge portions of code less often.
-
If the editor requires an extra RAM page, could it be kept separately for people who don't want to use it? As for the fonts I think they are fine, from what I saw earlier in the screenshot.
-
@DJ_O: That is the main reason for why I want to keep it separate. For people that only want to use Grammer 3 programs, the extra flash page for the editor is kind of a waste. Whereas for developers, it is useful. Plus, the editor app should be functional on its own.
That said, I only have 5800 bytes of code space left and I haven't even started the editing part of the editor :/ I will probably remove the variable width font and if users really want to use such a font, they can load their own. Also, for the indenting, I have come into a problem that I am trying to fix. Trying to scroll backwards isn't working very nicely at the moment for the indents, but I am hoping that I will have a fix. However, the perfect solution might cause a hit to speed for the editor (scanning all of the code before it to figure out the indent). For now, here is a screenshot of viewing the code :)
-
Looking nice!
And did you see my link for the real( and omnicalc tokens?
-
I personally hope that the fonts are monospace, since otherwise it can be annoying to edit in-game text (aligning it properly, I mean), or in the case where someone decided to use the editor for BASIC, editing string-based maps (like in Illusiat 13)
-
@Sorunome: I saw the link. Unfortunately, the readme doesn't equate the real( commands to tokens, so instead just opened the source and found the code for the menu. I now need to add in the DoorcSC7 commands, BatLib commands, and make a separate hook for Axe, Grammer 2, and whole token set for Grammer 3.
I have some goals for today and hopefully I will get something more useful done.
-
Good luck :)
-
Also, for the indenting, I have come into a problem that I am trying to fix. Trying to scroll backwards isn't working very nicely at the moment for the indents, but I am hoping that I will have a fix. However, the perfect solution might cause a hit to speed for the editor (scanning all of the code before it to figure out the indent).
All the code O_O? Maybe you could create an array in memory that has the indent amount for each line instead? I know computer text editors often cache information like that.
-
That was one idea I was thinking of, but that could get hectic when lines get inserted or removed, or especially when something like a While statement is inserted or an End statement is deleted. My other idea was to choose 4,8, or 16 points in the program and record the indent level their. Then instead of scanning all of the code, just start scanning from the closest recorded position.
My final idea is to toss it out entirely :P
-
That was one idea I was thinking of, but that could get hectic when lines get inserted or removed, or especially when something like a While statement is inserted or an End statement is deleted.
You could do what some IDEs do and have both the opener and closer (not actual technical terms, AFAIK) for the block inserted at the same time. The small-scale version of this is inserting a ')' when a '(' is typed, to clarify what I'm saying.
-
That is a good idea. So when the user uses a For(, Then, While , or Repeat , automatically follow it by an End. Hopefully I will put together a decent solution. I am thinking that all I really need to do is keep track of the indent level at the last displayed line and the first.
-
I like the automatic end idea. Of course it can be a bit annoying when you insert a for loop after writing most of the code inside it, but then you only have to delete the automatic end then add it below the code.
If I remember correctly, the HP 39gII added End instructions automatically.
-
Would it be possible to delete the margin on the left of the screen which appears when all the lines have at once one tabulation?
-
Hey Xeda, the editor is looking quite nice. :) Support for custom fonts is a neat idea too, but I'm not sure how much it'll be used.
-
Hi! Sorry for asking but is the project discontinued?
-
I think pretty much every project in the staff project section is either dead or completed. The exceptions are Ndless and TI-Boy SE.
-
As much as I want to continue projects, it is too much work for me. I might complete it eventually, but I doubt any time soon. Sorry :/
-
awe :(
I hope you'll be able to pic it up, though :)
-
Me too, it's just I haven't really had the drive and focus for a long time. Plus, Grammer 2 was easy, but Grammer 3 will be a massive under taking. SirCmpwn has been trying to encourage me to port Grammer to KnightOS, but I would probably make a "Grammer 2.5" for that. As it is Grammer 2 is almost OS independent, so a few macros should be able to make it easily portable between OSes.
-
You know I just saw this. Looking for an appropriate place to post a new Grammer forum. I was thinking about having KnightOS on my second calc. But I didn't see any good way to still code like BASIC. I wish I knew how to port.