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

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> 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

Nice one. That would indeed be handy.

> 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.

I haven't paid much attention to loop handling yet, but nested loops are handled
by recursive calls, and I guess aborting parsing is done by throwing an
exception; so it would mean adding...

- a local variable to count loop iterations while in a loop
- code to catch the exception while in a loop, and throw it onward with added
information about the current loop
- code to pass the detailed information to the front-end
- code in the front-end to output the information

Nothing that sounds dramatically complicated.

Being on it, it would be nice to have the same mechanism kick in if parsing is
aborted for any other reason.

Another thing that would greatly faciliate debugging would be a simpler syntax
to output a single variable, so that for instance

  #declare Foo = 47.11000;
  #local Bar = sphere { <0,0,0>, 1 }

  #debug_var Foo, Bar
  #debug_var Foobar

might print:

  Foo (global): 47.11
  Bar (local): object
  Foobar: undefined

Post a reply to this message

clipka wrote:

> "scott" <sco### [at] scottcom> wrote:
>> I'm not saying it's possible to detect whether any program will stop or
>> not. I'm saying that in *some* cases you can relatively easily detect
>> that it won't stop without changing the functionality.
> 
> I'm definitely repeating myself here: Those easy cases would come packaged
> with too many not-so-easy special cases.
> 
> Sure you can detect a simple
> 
>   #while (i < N)
>     //#declare i=...
>   #end
> 
> as being an infinite loop, but that's an absolutely trivial case; as soon
> as you go from there to
> 
>   #while (i < N)
>     ...
>     //#declare i=...
>     ...
>   #end
> 
> then if you don't find a "#declare i=...", you *must* examine the "..."
> thoroughly before you can conclude that the user really forgot it.
> 
> Of course, if you *do* find a "#declare i=..." in there, you can tell for
> sure the user did *not* forget it; but that doesn't get us any further.
> 
> The bottom line is that a potentially-infite-loop detector would be a
> quite complex piece of code, even if it were just to catch some standard
> cases. There would be much easier and more useful remedies for the
> forgotten-increment ailment.

I think most of the cases previously posted here are actually solvable. That
is, you can avoid thinking it's infinite when it's not (you can't avoid the
opposite, but it's OK, we don't have to detect all cases, and it's
impossible anyway). I have yet to see someone post a convincing code
snippet that would give a false positive.

#declare I=0;
#while (I < Limit)
   //...
#end

If neither 'I' nor 'Limit' are ever mentioned inside the loop, it's
infinite. Otherwise, it may be infinite, but assume it's not and let it
run.

#declare I=0;
#while (I < Limit)
    //...
    #include "file.inc"
#end

Just assume it's not infinite if there is an include, since it's prone to
way too many variables. For example, the user could edit file.inc in the
middle of the parsing to have #declare I=Limit;

Post a reply to this message

Nicolas Alvarez schrieb:
> #declare I=0;
> #while (I < Limit)
>    //...
> #end
> 
> If neither 'I' nor 'Limit' are ever mentioned inside the loop, it's
> infinite.

Not necessarily:

#macro Next()
   #declare I=I+1;
#end

#declare I=0;
#while (I < Limit)
   Next()
#end

No mention of I anywhere in the loop, yet perfectly finite.

You *must* dig into *every* macro to catch this.

Post a reply to this message

> #macro Next()
>   #declare I=I+1;
> #end
>
> #declare I=0;
> #while (I < Limit)
>   Next()
> #end
>
> No mention of I anywhere in the loop, yet perfectly finite.
>
> You *must* dig into *every* macro to catch this.

The parser re-parses the macro every time it is called though, doesn't it? 
So the parser simply needs to look out for any "#declare I" any time it is 
parsing commands within the loop, no matter if it is in a macro or not.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > #macro Next()
> >   #declare I=I+1;
> > #end
> >
> > #declare I=0;
> > #while (I < Limit)
> >   Next()
> > #end
> >
> > No mention of I anywhere in the loop, yet perfectly finite.
> >
> > You *must* dig into *every* macro to catch this.

> The parser re-parses the macro every time it is called though, doesn't it? 
> So the parser simply needs to look out for any "#declare I" any time it is 
> parsing commands within the loop, no matter if it is in a macro or not.

  It doesn't necessarily parse it every time. You could have something like:

#declare I=0;
#while (I < Limit)
    #if(rand(someSeed) < 0.5)
        Next()
    #end
#end

-- 
                                                          - Warp

Post a reply to this message

>  It doesn't necessarily parse it every time. You could have something 
> like:
>
> #declare I=0;
> #while (I < Limit)
>    #if(rand(someSeed) < 0.5)
>        Next()
>    #end
> #end

Ah yes, I think the conclusion we came to before is that anything that 
involves macro calls has to be assumed finite, because as clipka said you 
would need to search all macros to see if 'I' was redefinied anywhere, and 
that seems a bit wasteful.

Post a reply to this message

clipka wrote:
> What should be the detection criterion?

Just do what JavaScript does: after x number of seconds ask the user 
whether he want to continue waiting or kill the script.

-Mike

Post a reply to this message

SharkD wrote:
> clipka wrote:
>> What should be the detection criterion?
> 
> Just do what JavaScript does: after x number of seconds ask the user 
> whether he want to continue waiting or kill the script.
> 
> -Mike

As long as it's a non-blocking request.  There are scenes which takes 
longer to parse than to trace, you know.


...Chambers

Post a reply to this message

"bgimeno" <bgimeno[at]persistencia[dot]org> wrote:
> The following code is perfectly valid to the present version, but does not
> produce anything.
>
> #declare FooCount = 0 ;
> #while (FooCount < 100 )
> sphere {<0,FooCount,0>,1 pigment { rgb< 1, 1, 0> } }
> // #declare FooCount = FooCount + 1 ; // note this missing line
> #end
>
> I suppose that a "detector" of infinite loops is it too much to ask?

   Yes, that is basically what Alan Turing showed many years ago.  The control
syntax of  POV-Ray is powerful enough that the halting problem is undecidable.

   What would be possible is a restricted syntax for looping ("dummy variables
for dummies"?) that could be checked and that would guarantee no infinite loops.
 For instance, a simple For-Next syntax in which the dummy variable could not be
modified within the body of the loop would allow most things that most POV users
want to do.

      On the other hand, unless nesting loops were also forbidden, you could
still easily write a nest of loops that would require 10^100 years to run; and
nesting is something that POV users would miss.  So I don't think there is any
good solution.

Robert Dawson

Post a reply to this message