All aspects of development in Analysis (which does not fit in another project)

FS#180 - means fails when run in a .pgm if !t is not specified

Attached to Project: Analysis
Opened by Jamie Hockin (jhockin) - Thursday, 10 May 2018, 20:11 GMT
Task Type Bug Report
Category Statistics
Status Assigned
Assigned To Torsten Bonde Christiansen (torstenchr)
Operating System All
Severity Low
Priority Normal
Reported Version 2.0
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


v1.0.0 and anything I build has this error

if a .pgm has the following:

means x;

Output will be shown and then get an unhandled error: index out of bounds(n)
where n is the line number in the .pgm

Does not occur when running from the editor. As best I can tell, something fails in the history unit, but I cannot step into the error, so not certain. The statement appears correctly in commandlog.pgm
This task depends upon

2018-05-15: A task closure has been requested. Reason for request: see last comment
Comment by Jamie Hockin (jhockin) - Saturday, 12 May 2018, 15:52 GMT
The error arises in unit history.pas

history.pas sees the statement from the .pgm and Idx is the line number within the .pgm.
However, in the case of csrFailure or csrCustom, Idx is used as an index of the list of statements issued at the command line (or via Editor Run), which includes only the run statement.
history sees the actual statement from the .pgm as Statement

The solution will be to be able to identify in history.pas that the statement leading to Failure or Custom was executed because of a run statement. So history should be bypassed altogether for the statements within a .pgm and only called when the run statement ends. Can this be done by modifying the AfterExecution list of actions when a run is active? Or have a property within Statement object that tells history to ignore it?
Comment by Jamie Hockin (jhockin) - Tuesday, 15 May 2018, 16:25 GMT
I committed a change in (trunk) history.pas that corrects this behaviour, to check whether we are executing commands from a .pgm.