Hey developers... RUN!

[Pete]

I mean what's up with RUN?

Do you guys remember some of the problems with RUN and CLEAR in QB64?

I had a recent run in with RUN, which I forgot about, and had to fix today. I did so by adding VIEW PRINT and b$ = INKEY$ before the RUN statement. Why? Because in QB64, RUN sometimes does not clear the keyboard buffer, and never resets the VIEW PRINT to the default value. Here is an example of the VIEW PRINT problem but it doesn't demonstrate the keyboard buffer problem. My 1500 line app does, but not this itty-bitty one, oh well..

Code: QB64: [Select]

1. ON ERROR GOTO trap
2. LOCATE 1, 1: PRINT "Press Enter to continue..."
3. VIEW PRINT 3 TO 23
4. DO
5.     _LIMIT 30
6.     b$ = INKEY$
7.     IF b$ = CHR$(13) THEN
8.         PRINT "You pressed a key!"
9.         EXIT DO
10.     END IF
11. LOOP
12.  
13. PRINT "Re-running program in 1-sec..."
14. _DELAY 1.5: CLS: _DELAY .5
15. b$ = INKEY$
16. ' Unremark the line below to fix the RUN issue.
17. REM VIEW PRINT
18. BEEP
19. RUN
20.  
21. trap:
22. PRINT "Error"; ERR; "Press Backspace to resume...";
23. DO
24.     _LIMIT 30
25.     b$ = INKEY$
26.     IF b$ = CHR$(8) THEN EXIT DO
27. LOOP
28. LOCATE , 1: PRINT SPACE$(80);
29. VIEW PRINT ' Just to allow the next run to print to the top again.
30. RESUME NEXT

Now can anyone remember if QBasic RUN ignored the resetting of VIEW PRINT, too? Maybe it did, in which case this is a compatibility "feature."

Anyway, the WIKI should mention the VIEW PRINT problem.

What the WIKI does reference is this...

Note: RUN causes a stack leak in QB64 if it is called from within a SUB or FUNCTION. Avoid when possible!

Has that been addressed since the WIKI article was published? If not, that's a bummer. I used to exit nested subs to re-run a program but I'm getting lazier with age, so now I due use RUN in my SUBs.

Sorry this code doesn't replicate the keyboard buffer issue, but it is involved too. The fix, again is to just add something to clear the buffer, as simple as nul$ = INKEY$, before executing the RUN command. Again, if not to be fixed, this stuff should be included in the WIKI, when time permits.

Pete

[SMcNeill]

Instead of using RUN, I like this 2 command replacement:

SHELL _DONTWAIT “thisprogram”
SYSTEM

Fixes all those issues of yours.  ;)

[FellippeHeitor]

Has that been addressed since the WIKI article was published? If not, that's a bummer.

No work has been done on RUN recently that I know of.

Instead of using RUN, I like this 2 command replacement

Even better, in case the user renames the exe:

Code: QB64: [Select]

1. SHELL _DONTWAIT COMMAND$(0)
2. SYSTEM

[Pete]

Well is that the position you developers want to take on this? If so, why not code that SHELL into the RUN command and be done with it in a future release? If it solves the stack problem, assuming there is one, like the WIKI states, that might be the best way to go; but I recall CLEAR has some similar problems that Rob didn't clear up, either. Remember this one?

Code: QB64: [Select]

1. 101
2. CALL testsub
3.  
4. PRINT "Hello World"
5. _DELAY 3
6. CLS
7. _DELAY 1
8. CLEAR
9. GOTO 101
10.  
11. SUB testsub
12.     STATIC testarray(1 TO 100)
13.     FOR i = 1 TO 100
14.         testarray(i) = i
15.     NEXT
16. END SUB

CLEAR does not "clear" the array, so the second loop causes an error.

I mean the SHELL thing, if used, presents a problem while in the developing (build) stages. For instance, right now I'm using untitled(5).exe, but if that gets changed, then I have to remember to change the SHELL call, accordingly. The same problem every time a build is changed myprog1.baas, myprog2.bas, etc. So it's really only viable on the finished product, but if you ever change the name of that program in a utility like Explorer, you're screwed!

Pete

PS I just saw Fell replied while I was typing this. I'll have a look see at: COMMAND$(0). I haven't tried that before. Thanks...

[doppler]

I never thought of using run within a program.  It was always a thing to do after loading, typing in a program and to restart an interrupted run.

The best theatrical use of "RUN" was in the movie Colossus the Forbin project.  After telling the computer to load a program designed to overload colossus.  He said: "Run".  To which the computer almost broke down.  Came back from almost dead and said: "You fool".  Then ordered a couple of executions.  Thank god QB64 has a potential memory leak and would crash.  I dread the though of being killed for  bad programming.  I have seen some bad programming in my time, they deserved to be hurt someway.  If only for the mental damage I suffered.

[Pete]

I never thought of using run within a program.  It was always a thing to do after loading, typing in a program and to restart an interrupted run.

The best theatrical use of "RUN" was in the movie Colossus the Forbin project.  After telling the computer to load a program designed to overload colossus.  He said: "Run".  To which the computer almost broke down.  Came back from almost dead and said: "You fool".  Then ordered a couple of executions.  Thank god QB64 has a potential memory leak and would crash.  I dread the though of being killed for  bad programming.  I have seen some bad programming in my time, they deserved to be hurt someway.  If only for the mental damage I suffered.

But what if you want to make a repeating Hello program, and you're keyboard is missing the D F, and T keys, so you can't code it with a DO:LOOP,  FOR:NEXT, or GOTO statement? Simple...

PRINT "Hello!"
RUN

:D :D :D

The thing is RUN is a coding tool, and like any other coding tool it should work properly within the coding language. Buggy is not a "feature" unless there's a horse involved. Cool, I managed to trash FreeBASIC in the process!

Back in QBasic days, RUN was the only way you could get giant programs to repeat, due to memory constraints. With QB64, it is more of a shortcut to zeroing all variables, clearing all view ports, closing all files, etc. At my advancing age, I'll take all the shortcuts I can find.

Pete

[FellippeHeitor]

Both VIEW PRINT and the keyboard buffer will be cleared in the upcoming version (I'll be pushing the fix today).

Also, that nasty ERROR 5 that kept being trapped after RUN was called is due to the recent changes to WIDTH to work with the $CONSOLE. I fixed that too (WIDTH is called internally when RUN is called).

Since I got my feet wet already (or my hands dirty, if you will), can you name anything else that needs resetting after RUN is called, Pete?

[Pete]

Let's see, for RUN and CLEAR we have so far...

------------------------------------------------------------------------------------------------------------------------------------------------------
STATIC variables and arrays need to be cleared.
VIEW PRINT needs to be restored to default full height.
Keyboard buffer needs to be cleared, including any key pressed after a SLEEP statement to RUN or CLEAR program.
Memory leak needs to be addressed when using either within a sub or function.
LOCATE needs to be restored to DEFAULT values CSRLIN = 1 POS(0) = 1
------------------------------------------------------------------------------------------------------------------------------------------------------

Things I haven't tested or tried before...

MOUSE positions
MOUSE buffer
PALETTE (Probably OK, as COLOR is reset just fine with RUN

------------------------------------------------------------------------------------------------------------------------------------------------------

Things that appear to be reset OK using RUN are...

COLOR
ON ERROR

------------------------------------------------------------------------------------------------------------------------------------------------------

OK, now here's a weird one you guys will need to decide how to tackle, just for continuity sake...

Code: QB64: [Select]

1. LOCATE 30, 1
2. COLOR 14, 1
3. PRINT "OK"
4. SLEEP
5. RUN
6.  

On the INITIAL run, QB64 determines, for whatever insane reason, not to use the default 80 x 25 screen, so it can accommodate what should be the out-of-bounds LOCATE statement. In other words, it doesn't throw the suspected error 5. QBasic compatibility maybe? Anyway, I think it should open the default screen and throw the error message. So run the program snippet above and initially it will set up a different screen, with enough rows to handle the LOCATE 30 statement, but when you press a key, it encounters RUN and it not use that increased row screen, meaning it will go back to using the default 80 x 25 one, which will throw an error at the LOCATE statement.

IMPORTANT: Guys, don't mess with CLS! In other words, don't make RUN clear the screen. A neat feature using RUN is to pass a foreground color matching background color character or line off characters, and have them read at the start of the program to seed variable(s). That saves the bother of using a data collection file.

Pete

That's all I can remember at the moment, but if I'm missing anything, it's because I haven't coded with it using RUN or it's been too long to figure out what program I had encountered the problem.

Pete


------------------------------------------------------------------------------------------------------------------------------------------------------



Mouse

[FellippeHeitor]

Current state:
- STATIC variables and arrays already get cleared (arrays even get deinitialized).
- VIEW PRINT will be restored. (fixed today)
- Keyboard buffer will be cleared. (fixed today)
- It's not a memory leak, it's a stack issue. To restart the program, QB64 needs to call its MAIN() function in C++ again, so you'd better watch for millions of calls to RUN from within SUBs, as that "issue" remains.
- LOCATE actually gets restored to DEFAULT values in QB64, although it didn't in QuickBASIC 4.5, I just tested.
- Palette does get reset.

There's no talking about restoring mouse positions or buffer as that wasn't something native to QuickBASIC, so it works as it does in QB64 (whatever behaviour you come to notice).

OK, now here's a weird one you guys will need to decide how to tackle, just for continuity sake...

It has been a design decision to enlarge the screen if the user tries to locate outside boundaries, so that has already been decided on since early versions of QB64. A program from back in the days wouldn't locate outside boundaries and a new program wouldn't want to use RUN (as people in the forums usually recommend not to, see above), so there you have it.

In conclusion, I'm pushing changes :-)

[FellippeHeitor]

New builds available at https://www.qb64.org/portal/development-build/ if you can give it a try.

[Pete]

Current state:
- STATIC variables and arrays already get cleared (arrays even get deinitialized).

It has been a design decision to enlarge the screen if the user tries to locate outside boundaries, so that has already been decided on since early versions of QB64. A program from back in the days wouldn't locate outside boundaries and a new program wouldn't want to use RUN (as people in the forums usually recommend not to, see above), so there you have it.

- STATIC variables and arrays already get cleared (arrays even get deinitialized).

Now I'm confused. This doesn't work in 1.3. Are you saying it was fixed sometime after 1.3, now, or actually wasn't fixed...

Code: QB64: [Select]

1. testsub
2.  
3. PRINT "Hello World"
4. _DELAY 3
5. CLS
6. _DELAY 1
7. RUN
8.  
9. SUB testsub
10.     STATIC testarray(20)
11.     FOR i = 1 TO 20
12.         PRINT i
13.         testarray(i) = i
14.     NEXT
15. END SUB

In 1.3, it errors out after RUN. Error 9 at line 13.... the STATIC array. YOu can use CLEAR in place of RUN and put it in a LOOP, and it still errors out.

Now for fun, let's MOVE that RUN statement INTO the SUB... You know, that bad programming method. Well in this one case, bad wins because now it works without RUN interfering with the STATIC array...

Code: QB64: [Select]

1. 101
2. testsub
3.  
4. SUB testsub
5.     STATIC testarray(20)
6.     FOR i = 1 TO 20
7.         testarray(i) = i
8.         PRINT i, testarray(i)
9.     NEXT
10.     SLEEP
11.     CLS
12.     _DELAY .5
13.     RUN
14. END SUB
15.  

Go figure? Well, it makes me glad that the only thing I was responsible for developing were x-rays... and at least they're are pretty black and white. :D I don't envy what you guys have to go through.

------------------------------------

It has been a design decision to enlarge the screen... Well, if that's the way you guys want it to work, all that is needed is a WIKI inclusion to explain it for LOCATE and SCREEN.

I look forward to trying out the new release, soon.

Thanks for improving RUN. Have a look at my comments, and tell me what you think.

Pete

[FellippeHeitor]

Well, if that's the way you guys want it to work,

Nah, it was already like that, by Galleon, when any of us came around I believe.

all that is needed is a WIKI inclusion to explain it for LOCATE and SCREEN.

So much needs attention on our poor wiki... wink wink... https://www.qb64.org/forum/index.php?topic=1539.0 ❤️