So, I have endeavored to create a program that will allow a user to combine a program and it's subroutines into one program. Right now, the general idea is to make the source the final product and reading each line, checking for the 'prgm' token, and if it exists, removing the 'prgm' tag from the string, and saving the resultant to a string - Str3 to be exact. Then, it reads the subroutine, and writes the output to the program.

While this seemed to be simple, insofar, it has proven to be very difficult. One of the problems that I have encountered is frequent crashes. Could the repeated read-write be the cause of this, or am I doing something wrong?

I'm fairly inclined to say that the crashes are because you're doing it wrong. What are you using to do this? Can you show us a simplified form of your code? What calculator(s) are you targeting?

I am targeting the TI84+CSE I am using the OS version 4.2, DCSE version 8.2.0 build 1603

My simplest code (note: I am using Str1 for the source, and Str3 for the subroutine)
My code is (rather ironically) divided into subroutines

Main :

Code:


Reading source:

Code:


Reading Subroutine:

Code:


Writing to source:

Code:

I don't know how you could efficiently figure out how many lines there are in a given program using the DCSE libs (something better than reading consecutive lines until you get an error code), but assuming you've got that figured out, then your code looks fine to me, although you will want to make sure that you write down the tokens exactly as they appear on your calculator ("Then, End, etc.") or else they will not be switched to tokens when you send this file to your calculator. You can check for the prgm token on a line with the inString() command like this:

Code:


EDIT: Why do you use subprograms so much?

1:
If you attempt to read line 0 (ans=0 when calling det(0)) it returns the number of lines in the program to θ
2:
I have noticed that when I read the lines, the tokens are preserved (that may be what is causing problems).
3:
I use so many subprograms because it helps me troubleshoot problems that don't necessarily cause TI-OS to throw an error. and I can get to those parts of my code faster. For example, if I were to have a program that gets an input, and outputs it to random points on the screen, and the points were not being randomized, rather than breaking the program, and hoping that I land somewhere near the problem, I can go straight to the subprogram that has the randomizing code, make sure that it is free of errors, then can check to make sure that my program flow is correct.
Another, more simpler way to say the above: It allows me to treat TI-Basic variables like objects, with the subprograms being 'methods'. then I use the main program for flow, and the subprograms for operations on the variables.
This has proven useful in many of my programs that I have made.

1:

Mind = Blown
2: It should not cause problems... remember the tokens are all in a string so as long as they stay in a string, they should be treated like characters... except maybe the sto► arrow and " teardrop quotes, which might be a bit iffy to mess around with in a string, but even those I think should be just fine.
3: It hurts my brain. ლ(ಠ益ಠლ)

It makes sense that the program's header would contain the length of the program. (what about... line -1?)

After I did some research (A.K.A I typed length("prgm) I found that the prgm token has a length of one, and with that being said, I needed to make sure that I didn't specify a string length greater than the length of the string, since I am removing the first 'character'.

How is the project going?

I am still encountering crashes, but my last try had been fully copying the code, but it was writing it backwards (Line 1 would be Line 5 in a 5-Line program) but each line was in order. I deleted me 'test' program, and then my calculator crashed. I am starting to think that it may be because I am constantly using the On-Break when I find an error.

New update:

I now have a working version, and it is archived, however, due to the issues with the crashing, I will probably be testing it for a while. One change I have made is to, rather than seeing how big the original file is, I am simply using a repeat loop since it is much simpler

Any ideas on how to break the program?

So far, I have noticed that frequent use of using the on-break (approximately 15 times) is the cause of the crash. I am also going to create a log-maker to help people analyze where their program is crashing. (I hope this will be much easier to do)

I am not sure I understand what you mean here...

Any code to compile to try to cause my calculator to crash during execution.

Cosidering the lack of a list of things you already tried, examples and the compiler itself, this a very hard question.
Try one with no subprograms, one with only one, one with many (Overflow proof?). Then try empty and large subprograms. And that's about all I can think of right now...

Here is my source code:

Code:

After a long hiatus due to the frustration with my code, and me questioning my abilities, I have decided to revive this project, and hopefully get it to work dependably. First, I am starting from scratch, and am taking a completely different approach than my original approach, hopefully this approach will result in a more simple code, and will therefore encounter fewer bugs, If my attempts at a pure BASIC version are successful, I do plan on making a Hybrid BASIC version also, simply for the aesthetics.

Current pseudo-code:



Code: