A further thought I had this morning rather than adding an *infinite* loop
checker or loop_limit variable.
Typically if a render is parsing too long and a user gets suspicious, the user
will terminate the program.  Currently this simply posts the message "Render
cancelled by user." plus stats.  It would maybe be of debuggin assistance to
also report the line number where parsing was at the time of interruption
(similar to how an error does) and also (if it may be possible) the current
number of iterations the current loop(s) have been through.  You would likely
want it to report the number of iterations for any currently active loop (in
the case of nested loops) as it could be any of them that are the issue, not
just the most recent (any closed or inactive loops can be ignored).

EG:

01 #declare i=0;
02 #while (i<10)
03  #declare i=i+1;
04 #end
05 #declare i=0;
06 #while (i<100)
07   #declare j=0;
08   #while (j<100)
09     #declare j=j+1;
10   #end
11 #end

The user breaks the program while it is at line 09.
The first loop is inactive [line 2: #while (i<10)] as it reached its #end
statement, but the next two loops [line 6: #while (i<100), line 8: #while
(j<100)] are currently active, however POV doesn't know which is the problem
(the user should be able to tell that the j loop is fine as it has its counter,
but the i loop is infinite as the counter was forgotten.

In this case, POV could report (similar to error reporting) something along the
lines of:

Render cancelled by user.
Break point:
File: C:\POVDIR\POVFILE.pov  Line: 9
     #declare j=j+1;
Active loop:
File: C:\POVDIR\POVFILE.pov  Line: 6
#while (i<100)
Iteration count: 12345
Active loop:
File: C:\POVDIR\POVFILE.pov  Line: 8
  #while (j<100)
Iteration count: 67


The user can reference this to see where the file was terminated (line 9) and
the iteration count of the current active loops (line 6: 12345, line 9: 67) and
pinpoint the problem.  From this the user can infer that it may be the line 6
loop that is the problem as it has gone through a larger number of iterations
(perhaps larger than should be expected), whereas the line 8 loop is within the
expected loop count still.  Further investigation would reveal the omitted i
increment statement causing the infinite loop.

All this would be done with breaking the current implementation of the SDL.  It
would simply require reporting of the current line (which should be easy as it
is already done for errors) plus the addition of loop counters.  I'm not
familiar with the code, but I should think it wouldn't be an overly difficult
task to add this as POV would already need to keep track of open loops within
it's code parsing.

Any thoughts?

-tgq

-tgq

Post a reply to this message