I have these two programs:
Code: prgmX
0
Code: prgmY
"2->Str9
"X->Str0
0:det(0
det(1
I would expect this to replace the "0" in prgmX with a "2". Instead I get a line not found. However, if I do:
Code: prgmY
"2->Str9
"X->Str0
0:det(0
Ans-1:det(1
Which doesn't make sense to do, but I tried it anyway, I get
Code: prgmX
..NUMSTNG
Code: prgmY
"2->Str9
"X->Str0
0:det(0
Ans-1:det(1}?..NUMSTNG???????????????????????????
Str9 also is "..NUMSTNG".
Additional things:
1) ExecArcPrgm should work with Str0 as the program name like all the other functions
2) ArcUnarcVar shouldn't draw an hour glass on the screen
3) ArcUnarcVar should take an optional argument, 0 for Arc, 1 for RAM, so it can work as more than just a toggle
det(0 is Readline, while det(1 is ReplaceLine.
I just did the same with prgmX as you, for prgmY:
Code: "2"->Str9
"X"->Str0
1:det(1
Replaced the 0 with a 2. Something I noticed with the old Celtic is you have to close quotes, otherwise it could get screwy with the program. But yeah, you needed det(1 to replace, and line 1 is Ans=1.
What you have there is basically what I have, but I get the length of the program with det(0 first. I'll try it with closed quotes and see how that works.
Ah, you aren't using theta, so that threw me off, since the amount of lines are stored to theta.
Oh, I see. Yeah, even with θ:det(1 and the quotes added I still get the same thing... When I tried to change the code and then run it again I got a RAM reset...
*bump* Not to be annoying, but has this been looked into at all? It seems like a pretty big problem. Even if I'm doing the syntax wrong (which doesn't seem to be the case), it shouldn't be causing these problems.
I would like to point out I wrote the following program in prgmY and X, similar to what merth had above, and got this:
Obviously, I would not put all the stuff after the det(1. Not sure if this is something that happened after running other programs that might mess with Celtic commands, or if this is a glitch from DCSE/libraries. :<
When I ran it, it spat out:
}?..NUMSTNG<a bunch of junk>
Yours spat out:
>DMS?2<a bunch of junk>
>DMS is 1. } is 9. "2" is 1 character. "..NUMSTNG" is 9 characters. I think the "?" we're both seeing is actually a zero. That's two bytes of length and then the contents of the string, followed by a bunch of junk. From this it looks like it's dumping the contents of the whole string variable (VAT entry?) into the program.
This was after a fresh RAM reset, and deletion of the appvars. Then I created prgmY, only difference between this instance and the previous, is that I closed my ) this time, but the garbage at the end is very different.
From IRC:
14:55 <@tifreak> And X changed line 1 to "2", and added a line
14:55 <@shaun> Just a new line?
14:56 <@tifreak> Yes
14:56 <@tifreak> Line 2 is blank
14:56 <@shaun> And what of Str9?
14:56 <@tifreak> Str9 has a length of 0
14:56 <@shaun> Okay, so then that's still consistant with my theory.
14:56 <@tifreak> Str0 is also a length of 0
I apologize for not having much time to address this set of problems; my personal life is in something of a shambles and work has been hectic as well. Anyway, that's an explanation, not an excuse, so let's try to get to the bottom of this. From the discussion, am I correctly ascertaining that giving a constant line number and using det(1) to replace a line works correctly, but using det(0) to determine the number of lines and then immediately running det(1) to replace the line does not work (and indeed causes various exciting flavors of corruption)?
Merthsoft wrote:
Additional things:
1) ExecArcPrgm should work with Str0 as the program name like all the other functions
2) ArcUnarcVar shouldn't draw an hour glass on the screen
3) ArcUnarcVar should take an optional argument, 0 for Arc, 1 for RAM, so it can work as more than just a toggle
I would be happy to implement all these things. The trick is just going to be implementing (1) and (3) in a backwards compatible sort of way.
If you look at my pictures, you can see what kind of program I wrote to get the glitch that shows up. All I do is try to replace a line, instead it replaces the line and adds a line in prgmX, adds a bunch of junk to prgmY.
merthsoft wrote:
However, if I do:
Code: prgmY
"2->Str9
"X->Str0
0:det(0
Ans-1:det(1
Which doesn't make sense to do, but I tried it anyway, I get
[code]prgmX
..NUMSTNG One of Iambian's "optimizations" from the original Celtic 2 that I failed to remove in my version makes det(0) set Str0 to ".NUMSTNG" when computing the number of lines in the program, even when it succeeds. Therefore, you should reorder your code to set Str0 after the det(0) call.
tifreak8x wrote:
If you look at my pictures, you can see what kind of program I wrote to get the glitch that shows up. All I do is try to replace a line, instead it replaces the line and adds a line in prgmX, adds a bunch of junk to prgmY.
And do I correctly detect that you have no det(0) call in your test programs? Or am I missing something there?
Nope, I don't, I just use the det(1). Everything after that is garbage the calculator adds to the program.
KermMartian wrote:
merthsoft wrote:
However, if I do:
Code: prgmY
"2->Str9
"X->Str0
0:det(0
Ans-1:det(1
Which doesn't make sense to do, but I tried it anyway, I get
Code: prgmX
..NUMSTNG
One of Iambian's "optimizations" from the original Celtic 2 that I failed to remove in my version makes det(0) set Str0 to ".NUMSTNG" when computing the number of lines in the program, even when it succeeds. Therefore, you should reorder your code to set Str0 after the det(0) call. Ah, okay. That'll fix one issue, but the other still stands.
KermMartian wrote:
tifreak8x wrote:
If you look at my pictures, you can see what kind of program I wrote to get the glitch that shows up. All I do is try to replace a line, instead it replaces the line and adds a line in prgmX, adds a bunch of junk to prgmY.
And do I correctly detect that you have no det(0) call in your test programs? Or am I missing something there? That is correct. Even with the det(0), I would still expect it to not trash the running program, or put an extra newline into the program. I think what you're doing with the program whose line you replace is <new string><newline> when it should probably be <newline><new string>. I noticed this when I was doing it with my program. I had something like:
Code: prgmWHATEVER
...
Return
0
I'm storing the high score into the end of that program to make it so I don't need another appvar. Well, when I did store the high score, it turned it into:
Code: prgmWHATEVER
...
Return500
Which seems wrong to me.
I am able to replicate this problem. I started with these two programs:
Code: PROGRAM:A
:"2"->Str9
:"X"->Str0
:1:det(1
PROGRAM:X
:A
:B
:C
I ended up with this prgmX: Code: :2
:
:C>DMS?
I'll look into this when I get a chance; due to work and personal life things, it might not be until tomorrow. I'll try to do it sooner rather than later.
*bump* To make things even more confusing, tifreak8x's C2TEST program, in its DCSE form, works properly. It creates a program named ATEST, inserts a series of lines into it, deletes a few lines, then deletes the program. At no point does it get funky content. So is it the length of the contest, the length or value of the program name, or something else?
Edit: Okay, I see the issue, ReplaceLine has a bug (that needs fixing), but InsertLine itself is fine. Would DeleteLine + InsertLine do what you need, Merthsoft? That way you won't have to force your users to use 8.1, but I will still fix this and other issues.
Edit #2: Yes, I confirm that det(7) (DeleteLine) + det(2) (InsertLine) appears to function correctly.
Some conflict between Celtic 2 CSE and xLIBC it seems D:
This screenshot demonstrates a Celtic-only game at first, then afterward, I edit the code with an xLIB command to erase the gray bar at the top, then see what happens:
Basically, somebody was making a game using Celtic 2 commands and I suggested him to use xLIBC's drawshape command to erase the 84+CSE gray bar leftover at the top of the screen. However, as the screenshot demonstrates, when you use drawshape commands, it messes up the TI-BASIC's Output command in a way demonstrated in the screenshot above after I edit in the drawshape commands.
The TI-OS expects the normal LCD mode ($1038, I think?) and an end_y of y=240 all the time. If xLIB touches either of those, I suspect that's the problem.
ahh ok, i think xLIB must be setting the wrong mode upon return, that will have to be updated.