Instructions after BYE at top level when loaded by command-line has strange...
A Logo programming environment for Microsoft Windows
Brought to you by:
david_costanzo
Menu
▾
▴
#484 Instructions after BYE at top level when loaded by command-line has strange behavior
If you run a program from the command line and that program has a BYE instuction, followed by another instruction, FMSLogo says there was "you don't say what to do with" error processing and it prompts you to open the editor. If you open it, it shows the "exiting with edit session open" error.
This is wrong for two reasons. First, I'd expect BYE to take effect immediatly and not to parse further instructions (or at least, not to complain about them). Second, the instruction is well-formed, so I do say what to do with the extra input.
Interestingly, this problem does not happen if you LOAD the file from an open instance of FMSLogo. Nor does it happen if you include the instructions in a procedure that is run from the "startup" instructionlist. That is, it only happens if the program is loaded at start and only if the BYE is at the top level.
This behavior is first reproducible in FMSLogo 6.9.0. I expect it's a regression caused by the fix for bug [#138]
Steps to Reproduce:
To reproduce this create a file name "repro.lgo" with the following contents
BYE
TONE 100 1000
Then run the program, either by double-clicking or running "fmslogo.exe -L repro.lgo" from the command-line.
Expected Result:
FMSLogo starts and exits. You never hear a tone.
What Happens:
FMSLogo starts and shows a dialog box that says there was an error loading the file. The error is "you don't say what to do with 1000". If you press OK to open the editor, the editor opens then you see a second dialog box that says "An Edit session is running, do you really want to exit FMSLogo", the same behavior as exiting when the editor is open.
Related
I have committed a fix for this, which will be available in FMSLogo 7.0. Now not only is the execution of primivites skipped, but they also act like they do not return a value. This follows the same code path as when an error is being thrown.
As the comment says, this was fixed in FMSLogo 7.0.0. I must have forgotten to mark it as fixed.