This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Runer112
Pages: 1 ... 16 17 [18] 19 20 ... 153
256
« on: August 01, 2014, 07:15:12 pm »
I'm quite satisfied with Noshell. I've already heard of zStart, but I think it uses more than a single flash page ! And my sources program are always unarchived (with some backups on my computer), in case of RAM cleared (this occurs quite often).
zStart is also only one page. It's basically objectively better than Noshell, and I would once again recommend you grab it.  It's a shame to prevent the program from being run by the OS just if you want to make sure writeback occurs ! Instead of preventing the user to execute the program if he hasn't got any shell, it's better to add a writeback routine inside the program ! I wrote a short code, which works when the program is shelled by the OS :
That actually looks relatively appealing. However, the potential problem I see is that, when run by a shell, it may not be the case that OP1 contains the name of the program being executed. Best case scenario, it doesn't contain the name of a variable, and no writeback occurs. Worst case scenario, it contains the name of another variable, perhaps Ans or some shell appvar, and then the writeback clobbers RAM. Maybe I (or you) can round up all the main shells (MirageOS, DoorsCS, CrunchyOS, Noshell, CalcUtil, and zStart) and test this. If OP1 turns out not to be reliable, it would be worth checking progCurrent, progToEdit, and nameBuff. EDIT: Alternatively, it may be possible to detect if the OS or a shell launched the program.
257
« on: August 01, 2014, 05:08:58 pm »
In fact, it raises a big question : should Axe become closer to TI-Basic with floating point maths, or should it stay closer to assembly and 16/8 bits maths ? Both cases are interesting, it depends what kind of program people make. But for beginners, being forced to use 16-bit is a good thing, because otherwise they would keep using floating point maths where they could use 16-bits maths, it wouldn't be optimized, and Axe would become a sort of TI-Basic II.
Integer types would exist in tandem with floating point types, and you would pick what type different variables/values are. It would be very similar to a language like C. No, without any shell, it's not the case ! Even if the program is stored in RAM ! Personnally, I use Noshell on my TI-83+ (OS 1.19), and I tried a little program "{GDB0}++:Disp {GDB0}>Dec,i", and the output is always the same ! But maybe, yeah, as a lot of people are using shells with the write-back option enabled, they face the opposite problem (which is easier to solve, by the way).
I'm not sure what I was thinking... You're absolutely correct that writeback doesn't occur when executing programs through the OS. TI just copies the program, runs the copy, and then deletes the copy. Noshell has an option to toggle writeback, so it should support it. Also, I'd highly recommend replacing Noshell with zStart. It does everything Noshell does, plus so much more. Notable features for Axe developers are the ability to edit programs without unarchiving them, so you never have to worry about losing your source in a RAM clear, lots of helpful editor hooks like jumping to labels by name, and shortcuts to compile your program without even leaving editor. Also, zStart runs automatically after RAM clears, so all of its hooks and behaviors reinstate themselves without needing to run it every time. Anyways, back to the topic at hand. Generally, as long as you run the program through any sort of shell/archived program running utility, writeback will be supported. So if you want to make sure writeback occurs, just compile your program with the MirageOS or DoorsCS header (I recommend the former, it's more widely accepted) to prevent it from being run by the OS. Everybody should really have a shell/archived program running utility on their calculator, so imposing this limitation shouldn't be a problem.
258
« on: August 01, 2014, 03:34:19 pm »
The first one is when you try to compile a program which has the same name as the source : you get an error, and pressing the [prgm] key will freeze the calculator during some seconds.
I get the "SAME OUTPUT NAME" error as expected, and going to error occurs instantly. I've also noticed that, when the compiled name takes more than 8 characters, the error "NAME LENGTH" appears in a strange way.
I'm not sure what you mean by the error appearing in a strange way. It seems fine to me. If you mean none of the progress bar and such have appeared yet, that's because the header of the program is parsed specially and before main parsing begins. And it would be great if, when compiling to a program instead of an application, the lowercase letters of the program name were converted into uppercase, instead of truncating the name.
This used to be the case, but when I rewrote header parsing, I removed this behavior. My reason for doing so was twofold: to make header parsing easier for me, and to implicitly prevent code that was meant to be compiled as an application from being compiled as a program. I figured that, if you encountered this error, you could just quickly convert the name to uppercase anyways and not encounter it again. Since I made this change, one dissenter has presented an argument against the change. He frequently develops applications and compiles test builds as programs to avoid the somewhat long application-writing pass, and as such, he needs to change the case of the name when switching between compiling test and release builds. But for being a relatively small problem that only one person has brought up and which can be worked around in a matter of seconds, I haven't had enough reason to change the behavior back. Like the "NAME LENGTH" error described earlier, when compiling to a program instead of an application, if the name contains more than 8 characters and uses lowercase, the error "INVALID TOKEN" will appear in a strange way, and pressing the [prgm] key will make the calculator freezing during a few seconds. Here's the hex code corresponding to that error, as it appears on the calculator :
00B
00000B0034CBB9DB
29DB4AF1800180B3
7004141150800861
CB0866662445C861
If the strange appearance is the same as the strange appearance I described before, that's expected. But I think I may have inadvertently reproduced the freeze you're experiencing. If my suspicion is correct, it's due to the fact that changing any Axe settings (anything in the options menu or the target compiled type) results in the Axe settings appvar needing to be modified and saved back to archive, which is done when Axe exits, whether to the homescreen or to an error in the program editor. There are also some problems with the multiline comments... If you end the comment the line after you started it, Axe Parser doesn't detect the comment's end, and make the error "MUST END COMMENT". And if, instead of skipping lines inside a multiline comment, you use colons, you get the same error.
I can reproduce this bug. I'll try to fix it, although Axe's comment/newline parsing has always been a bit wonky, so it may not be as easy as it would seem. An other little bug for the road : trying to display a string ending with the [sto] arrow generates the "INVALID TOKEN" error.
Axe has tried to be friendly to BASIC coders used to newlines and store arrows closing/breaking out of any open parentheses, braces, or quotation marks. As a result of this, like in BASIC, you can't include a store arrow in a string, because it immediately ends the string and is parsed as a normal store arrow. However, unlike in BASIC, there are other ways to include data which, although a bit messy, let you include a store arrow in string data. If you know the character code for the store arrow, which is 0x1C, you can plop it in the middle of string data, like "ABC"[1C]"D". You could also do this without directly providing the character code because fetching the character code for the store arrow is valid, like "ABC"Data('→')"D". However, take note that strings need a null terminator byte, which is provided automatically when a line of data ends with string data. It would not be provided automatically in a case like "ABC"[1C], so you would need to make the line end in string data, like "ABC"[1C]"", or add the null byte yourself, like "ABC"[1C00].
259
« on: August 01, 2014, 02:42:05 pm »
First, you should add a command (and maybe associate it with the "Prompt" token) which inputs a number, because it's useful and a lot of people need this ! Probably use the "input" command, and then parse the returned string to convert it into a 2-byte number. You can make it able to convert the number into a float. For example, the command's syntax could be "Prompt A" to get a 2-byte number, and "Prompt float{A}" to get a float number located at the address pointed by A.
I'm hesitant to add built-in input routines because there are so many formats in which a programmer may expect their input: decimal/hexadecimal, signed/unsigned, integer/float, home/graph screen, maximum number of digits... it goes on. Many of these would require a fair amount of custom code not provided by the OS. I already don't like the existing input command because it's very non-ideal, clearing the entire home screen, reading in tokens rather than characters, and not allowing any sort of keypress-time validation (for instance, only allowing digits to be entered for a number). So input is something I figure is best left to the programmer, who knows exactly what they want and how they want it to be input... Unless you know how to remedy my woes with input, in which case I'd love to include some more powerful default input commands that are mildly robust and programmer- and user-friendly. Talking about float numbers, here's another idea : it could be great to add the support in Axe of float numbers, by using the OS's bcalls. The tokens could be Axe's regular math tokens, with a dot just after, and the values would be located at the addresses pointed by the variables. For example, "A*.B->.C" would be compiled liked "Copy(A, OP1, 9):Copy(B, OP2, 9):bcall(FPMult):Copy(OP1, C, 9)". But maybe use the bcalls Mov9ToOP1/OP2 instead of Copy(VAR, OP1/OP2, 9).
I've discovered there's an Axiom that allows this kind of manipulation with the OS's float variables, but it would be better to have it the way I described it, without having to use the OS's variables. Because it leads to creating the variables if they do not exists, looking in the VAT for the variable's address, and lose time. It's better if we use adresses of free memory for temporary calculations (in safe RAM areas, for example) and it's even better because it doesn't modify the OS's variables, if the calculator's owners stored important data inside them. It makes me thinking that it would be great to have a way to allocate/deallocate memory to a program, like "GetCalc(" does, but without having to specify a variable name, only the size needed.
I absolutely agree that Axe could use floating point support. But if I'm going to add it, I'm going to do it right. That means growing out of the everything-is-a-16-bit-integer system and providing actual types. So for now, ugly Axioms will have to suffice. But if and when Axe 2.0 comes out, this will be included. And, talking about memory, why not also add a way to save the program's self changes from $9D95 to the compiled program ? It can be usefull for people developping games, instead of using an appvar only for the two bytes of the best score !
If a program is in RAM when it is executed, it will simply be moved to $9D95, executed, and then moved back. So any changes made to the program during execution will be persisted because they were written directly to the sole copy of the program. If a program is in archive when it is executed, then it must have been executed by a shell or something similar that either unarchived or copied the program to RAM. If it was unarchived, then just like normally running a program from RAM, writeback is implicit. If it was copied, then writeback must be performed by deleting the original and archiving the copy, which I believe is done by all shells that use this method. So no matter how you execute a program, writeback should occur. In fact, the only problem should sometimes be preventing writeback rather than providing it. But this is something unavoidable that the programmer has to work around. Generally, the appropriate thing to do with data that you don't want to be written back is to locate it in RAM outside of your program. And I kept the best for the end : to implement a "Menu(" function, by using the OS's DIALOG bcalls ! I know you probably already thought of it, and it may be very complicated, but it's an important and so useful command ! I saw an amazing use of these bcalls in Brandonw's calcstuff, in the compressed folder "ddemo.zip", described in "dialogNotes.txt"... But it would be great to have at least the equivalent of the TI-Basic "Menu(" command.
I'd love for this to exist as well. I just have absolutely no clue how the OS dialog/menu system works, so have been unable to try to add it myself. If you think you know enough about it to be able to contribute this feature, that would be awesome. And I forgot to talk about another feature I thought about. In some cases, it could be useful to have Axe's variables located in a specified data, to save/load default values easily with the "Copy(" command. I think the syntax "[X Y S ]r->GDB0" is great. And it could allow the programmer to add customs variables, with two-letters name : if he writes "[XpYpXeYe]r->GDB0", he could then use the additional variables Xp, Yp, Xe, and Ye. (It's not that 27 variables are not enough, it's rather that I prefer to use variables with a name that evokes me something, and sometimes I need several variables to memorize X and Y coordinates !)
Axe's letter variables are stored in contiguous memory in alphabetical order, and you can retrieve the address of any variable with the °A syntax. So reading/storing contiguous variable values in bulk is absolutely possible. Perhaps I could think if there's some easy way to enable the default one-letter variables to be relocated so that variables not in contiguous alphabetical order can occupy contiguous memory, but it doesn't seem like a high priority to me. Especially because you can locate variables with non-contiguous names in contiguous memory by reading on. Custom named variables were one of the biggest additions in Axe 1.0.0, and have as such been around for quite a while. Just as you use the °VAR syntax to retrieve the address of a variable, you use the addr→°VAR syntax to "store" a constant address of a variable so that VAR is then a variable that exists at the constant address addr. This same syntax is also Axe's mechanism for defining constants; store a constant value as the "address" of a "variable," and just read back the "address" in your code, never using it as an actual variable. However, note that, because of weird internal compiler reasons, the constant address cannot be a reference to a data section inside your program.
260
« on: August 01, 2014, 12:03:45 pm »
Hi ! I've been using Axe for one year now (since version 1.0.0), and I love it !
It's way much faster than TI-Basic, and it's even easier to use ! Thanks for making Axe Parser !
I have some little ideas to improve it... Here's my contribution !
Thanks for the praise! It's always nice to occasionally be reminded that Axe is appreciated. And it's great to see you have such an interest in it that you're already coming with suggestions backed by assembly knowledge. First of all, Axe Parser should check if there's any backup kept in RAM and either 1] show it in the "Compile" list or 2] ask to archive it. Because one day, just after compiling, it asked me for "Garbage Collect" like it does sometimes, and I answered "no" by mistake. I then thought my source was lost, because the source program was removed and its backup wasn't shown in the compile list (as it wasn't archived). I spent one hour to write the full source code again from memory, beause I didn't know the backup was kept in RAM !
Weird... backups in RAM indeed aren't displayed in the list. I've made a note to fix that. I have an idea to improve the drawing functions... I think that games made with Axe Parser are sometimes slow, especially when they use grayscale graphics on a TI-83+, without the "Full" mode. So why not adding new drawing functions like "Pt-On(", "Pt-Off(", etc. but wich draws sprites only on full bytes of the buffer, each 8 pixels, for 0<=X<=11 ? These functions could be accessed by adding a letter to the other drawing functions' name, "C" for example (stands for "column" and "clipped"), and could be named "CPt-On(", "CPt-Off(", "CPt-Change(", "CPt-Mask(", "CPt-Get("... Also, you could add "CHorizontal +/-" and "CVertical +/-" to move the screen by 8 pixels. I wrote all these drawing functions in assembly if you want (although they may not be fully optimised).
I did a quick analysis of the sprite routines, and the amount of extra time they spend compared to aligned routines is actually not that much. The clipping code is pretty good about finishing fast if no work needs to be done, and if the x coordinate is a multiple of 8, the code switches to an aligned output code path with no rotates and such. My quick estimate suggests that the total overhead when drawing aligned sprites is only about 15-20%, which, to me, doesn't warrant adding entirely new versions of all the sprite commands. There are other contributing factors as well; they'd probably only be used by a handful of more advanced coders, and they would take up a lot of extra space in the application, which is already severely lacking. Functions to shift the screen by more than one pixel at a time have definitely been on my to-do list for a while. But, like with the sprite situation, I think I'd prefer a general unaligned routine that's more capable and appealing to the average coder, but which uses a faster code path for aligned shifts. I should really start working down the to-do list, it's massive... And to improve the datas, I think it could be great if we were able to make datas with binary values. To differentiate them with hexadecimal values, you could add the prefix "pi" to the data, like "pi[0101101010011001]->GDB1".
Hayleia answered this one pretty well already. Although not quite as compact as a blob of binary digits, Data(π01011010,π10011001) would provide this functionality. If you're entering binary data, you probably already aren't too worried about compactness, anyways. I imagined others features and functions, but they will be much more complicated to do...
Shoot.
261
« on: July 30, 2014, 05:01:47 pm »
Applications on the computer are stored in a format that inflates the data by about 2.4 times the size. The actual application, when sent to the calculator, will be smaller.
262
« on: July 30, 2014, 04:11:48 pm »
So, I have a couple of questions.
Can we assume the input is at least 2? Otherwise, largest prime factor doesn't actually exist.
Also, can my output have a trailing space? That makes things easier in TI-BASIC because of silly string limitations.
If yes to both of these, then I have a 67-byte TI-BASIC solution.
Assuming that the input is at least 2 and an integer is fine, since any other numbers do not have a greatest prime factor. But I'd be of the opinion that a trailing space is not okay, especially in the case of TI-BASIC, in which the trailing space would become obvious when doing something like recalling or otherwise operating on Ans.
263
« on: July 28, 2014, 07:36:49 pm »
By the way, if your language does not support underscores (ONLY if it does not) you may use a decimal [.] symbol instead.
For the record, 83+ BASIC does support underscores (see this post). For consistent scoring of such entries, I'd suggest that all 83+ BASIC entries should be scored as if they used underscores (two byte tokens) rather than periods.
264
« on: July 28, 2014, 12:04:31 pm »
Here's my suggestion for the next challenge:
Input: a positive integer of reasonable size
Output: The highest prime factor of that integer, in binary, but with all 0s replaced with underscores (_) and all 1s replaced with minus signs (-)
Example:
Input: 15
Output: -_-
Example:
Input: 7
Output: ---
Example:
Input: 115
Output: -_---
This is the kind of creatively new yet simple challenge that I wish I could think of. I don't think there are underscores in TI BASIC, but I'll try if you win
There is an underscore token, although it's not typeable on a calculator through normal means. It's two-byte code is BBD9. It could be entered either in a computer tokenizer or perhaps produced by an on-calc tool made for producing untypeable characters, like this.
265
« on: July 24, 2014, 07:28:21 pm »
The simple way is to draw it using the Bitmap() command, for which you specify the specify the sprite's dimensions by putting its width (1 byte) followed by its height (1 byte) at the start of the sprite data. You can either insert these at the start of the hexadecimal sprite data (in hexadecimal), or if you want to enter the size in decimal numbers, the following would be equivalent: Data(20,20)→Pic1
[(picture)]
Note that each row of image data must be padded on the end with zero bits such that each row takes up a whole number of bytes; in the case of a width of 20, each row should consume ceil(20/8) = 3 bytes. It doesn't seem like your data follows this, so you'd need to amend it.
266
« on: July 23, 2014, 03:29:52 pm »
Words are made up of any printable characters except for the space. Trailing, leading, and repeating spaces are valid, but shall be deleted so there is only one space between words upon output.
Are we sure this is the official ruling? Because when I asked willrandship his thoughts in IRC yesterday, he gave basically the opposite answers; words made up of alphanumeric characters only, and no trailing, leading, or repeating spaces. I personally prefer willrandship's view, because it gives a better chance to languages that don't have string splitting/regex functions and generally allows for more golfed/hacky solutions.
267
« on: July 23, 2014, 09:38:08 am »
Can we get some official clarification on input format, JWinslow23/willrandship? The main questions that come to mind are: - Are words/clusters composed of alphanumeric characters, any printable characters, or something in between?
- Are leading, trailing, or duplicated (successive) spaces valid?
A good way to solidify all of these rules at once could be to specify a regular expression for valid input.
268
« on: July 16, 2014, 12:49:56 pm »
I added it in.
I also added something of my own...let's see Runer112 try to golf this TI-BASIC entry... 
If he asks, though, I'll show it in a spoiler. 
Why would I want to see it? If I want to beat it fairly, I shouldn't get to peek at it. EDIT: Only about 5 minutes later, I've figured out how to get it down to 49 as well. Did you use my initial entry and see the same optimization? Or did you develop yours completely independently? EDIT a while later: Down to 48!
269
« on: July 15, 2014, 05:10:25 pm »
Why count newlines as two characters? I believe that basically any modern interpreter/compiler accepts either Unix-style or Windows-style newlines, so surely in the spirit of golfing you'd want to use the one-byte option?
270
« on: July 14, 2014, 09:13:06 pm »
Do you/others think it's better for entries to be messaged to you privately, rather than just posted here in a spoiler?
Pages: 1 ... 16 17 [18] 19 20 ... 153
|
Show Posts