Grouping A Program / Discussion

Forum Attachments

This is the discussion related to the wiki page Grouping A Program.

Bit Changing

DarkerLine 25 Mar 2008 01:55

Quoting James Kanjo's recent change:

WARNING: The grouping feature is NOT foolproof. If you group a program with significant size, during the "Ungrouping" process, the calculator tends to change one bit in the coding (often changing one command or variable into another around the middle to the end of the program) and often returning an error when the ungrouped program is executed. For this reason, grouping is NOT recommended.

You're right to say that this is a warning "the TI-Basic community may have previously been unaware of." In fact, I wasn't aware of it myself. I was also unable to reproduce the result: I created several programs ranging from 8000 to 20000 bytes in size (definitely "significant"), and was able to group and ungroup them without any trouble (and the code wasn't changed in the slightest, either).

Could you provide a way to reproduce this error on a calculator (e.g. give a program that this happens to)? I would be interested in seeing it. There are also other possible explanations:

• The bug occurs only when archiving some specific variable.
• An assembly program you've used on both calculators is the cause of the bug.
• The bug occurs randomly, and I wasn't "lucky" enough to encounter it.
• The bug depends on OS version, and mine (1.15) is too ancient to have it.
• Something about the hardware that varies from calculator to calculator.

In any case, giving step-by-step instructions to getting this error will help us figure out what causes it, and if it can be avoided.

I'm going to reword the article to not state the WARNING: so categorically at this point, pending further testing.

Re: Bit Changing

GoVegan 25 Mar 2008 03:16

Okay, I must confess. This error happened to me repeatedly 2 years ago, and it was only last year that I discovered it was the Grouping Process.

I did various tests, including copying the program, grouping the copy, and ungrouping the newly created group. I was mortified to see that a Disp "Blah blah","blah blah blah" had turned into a Disp "Blah blah blahgetKey,"blah blah blah". I remember doing repeated tests over and over again.

In one particular test, I deleted one bit at the start of the program, and the changed bit after re-grouping was exactly one bit after where it previously was (i.e. Disp "Blah blah blah"getKey"blah blah blah"), and I conluded that the error happened after a certain memory usage point, thus the bug does not occur randomly. It was notable that the same bug happened exactly the same number of bits after the first happening within the same program. Because it was last year, and I foolishly didn't document this, I can't remember what number of bits it was, but it was around 4000.

Just to make sure that it wasn't just my calculator (in case I bumped/dropped/whatever it) I did the same tests on my friends TI-84plus, redering the same results, and the same tests on my other friend's 83plus. So this means it is highly unlikely that the there was the same unique hardware problem in all three of our calculators, and thus it is not a hardware error. It is also notable that because the test rendered the same results on the 84plus, that it is also unlikely that it was an OS version error.

I didn't test a combination of variables archived, but I do remember doing a "Program + Real Variable A" combination, and also a "Program + Program + Program" compilement. Because of the same rendered results, I would also think it is unlikely that it had something to do with archiving a specific variable.

However, it is possible - even probable - that an assembly program had something to do with it. Seems as we all exchanged and played the same games and using the infamous Mirage OS to run them, it is possible that a "Keyhook" Mirage, or even another program for that matter, had implemented something which affected the Grouping process. I had not even considered that one.

I am currently trying to mimic my results (having backed up my programs, reset all ram and not gone near the Mirage OS, I feel that if I render the same results that it may not be an assembly program), however, I am finding it difficult as my computer-calculator cord self destructed 6 months after I started using it about 3 years ago, and I am analysing the programs manually. If I could link the two, I could use a computer application to do an instant comparison between the two programs and highlight the differences, instead of this tedious human analysing method I'm currently doing. Is that the way you did it DarkerLine?

Anyway, I'll come back after further results.

Cheers ~ James Kanjo

Re: Bit Changing

DarkerLine 25 Mar 2008 14:08

Okay — first of all, you're saying "bit" when you mean "byte".

My method of checking the program was to create a large program which stored "XXXX….X" to various strings (with lots of X's to achieve the necessary size). I then wrote a program which would check a string to see if it had any characters other than X in it. Of course, if the changed byte were not an X, the result would be a syntax error instead (which would also demonstrate a difference).

Re: Bit Changing

GoVegan 25 Mar 2008 22:10

Yes, I was following suit when you titled it "Bit Changing". As you hadn't corrected me in the first one, I didn't know I was saying the wrong thing. Yes, it is not possible for it to be a bit, is it? A bit is either a zero or a one. Silly me.

But hang on, that doesn't quite make sense. If you had a program like this:

"XXXX→Str1
"XXXX→Str1
"XXXX→Str1
"XXXX→Str1
"XXXX→Str1

And then a program to check which if Str1 has something other than X, how can it tell if something is changed in between? For example (which is most probable):

"XXXX→Str1
"XXgetKeyXX→Str1
"XXXX→Str1
"XXXX→Str1
"XXXX→Str1

Then how could the checking program detect that? As Str1 is changed back to how it should be before it is detected, then we will never know there was a changed byte.

Re: Bit Changing

DarkerLine 25 Mar 2008 23:45

How about this:

:"XXXXX→Str1
:"XXXXX→Str2
:"XXXXX→Str3
:"XXXXX→Str4
:"XXXXX→Str5

This also enables you to find, approximately, in which part of the program the error occurs.

If the program needs to be really large (say, more than 12000 bytes) then you'd want to archive the strings after storing to them, to avoid an ERR:MEMORY.