This will be fixed in POV-Ray 3.6.2.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> The cause is an interaction of Parse_RValue's Temp_Count with a turnaround
> of token_count in Get_Token.  If you change the last declare in the given
> example to "#declare N=N+1-1+1;" you will see that the first such
> coincidence occurs at N=72 with a period of 290.  If you break in the
reset
> of token_count in Get_Token you can follow the cause.

I don't quite follow you, but since you seem to understand the problem, do
you think there is any sort of workaround (aside from never relying on
passing variables by reference)?

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

In article <41a61527@news.povray.org> , "Slime" <fak### [at] emailaddress> wrote:

>> The cause is an interaction of Parse_RValue's Temp_Count with a turnaround of
>> token_count in Get_Token.  If you change the last declare in the given
>> example to "#declare N=N+1-1+1;" you will see that the first such coincidence
>> occurs at N=72 with a period of 290.  If you break in the reset of
>> token_count in Get_Token you can follow the cause.
>
> I don't quite follow you,

The problem is a lesson why today good books on good programming practice
will tell you to define constants once and use them by name rather than by
inserting the constant's value everywhere.  If that practice had been well
established when POV-Ray was initially written (or 3.0 ten years ago for
that matter), this problem could not have occurred.  In Parse_RValue
token_count is compared against two constants (-1 and 1000) inserted by
their value.  As it turns out (the code was never commented) the second
constant there needs to match the same constant in Get_Token...

> but since you seem to understand the problem, do
> you think there is any sort of workaround (aside from never relying on
> passing variables by reference)?

First of all, only references to vectors and scalars will be affected if and
only if a 5000th token parsed happens to be the last token of a macro call
argument list.  If this happens, then POV-Ray decides that the argument is
an expression and not a declared value and passes it by value, not
reference.

Now, anybody who knows what counts as a token and what does not in POV-Ray
can work around this (hint: the documentation tells).  Everybody else should
consider twice if passing by reference is really necessary.  In many cases
it is not at all anyway!  Those who want to do neither will have to wait for
POV-Ray 3.6.2 or use POV-Ray 3.5.  Sorry!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Wasn't it Slime who wrote:
>
>I don't quite follow you, but since you seem to understand the problem, do
>you think there is any sort of workaround (aside from never relying on
>passing variables by reference)?

You could load the variables with values that the macro is unlikely to
return, perform tests after the macro call to see if they're unchanged
and call the macro again. Because the problem occurs at widely separated
intervals, a second call will succeed. You need to think about whether
the macro has any side effects which shouldn't be duplicated.

E.g. in the original Tsutomo Higo scene we could write:

 #declare M = 0; #while (M<3)
   #declare Cp[T][L][M] = 12345;
 #declare M = M+1; #end
 Wave (Cp[T][L][0], Cp[T][L][1], Cp[T][L][2], T+Ncase, L)
 #if (Cp[T][L][0] = 12345 | Cp[T][L][1] = 12345 | Cp[T][L][2] = 12345)
   Wave (Cp[T][L][0], Cp[T][L][1], Cp[T][L][2], T+Ncase, L)
 #end

The Wave() macro doesn't have any side effects and can't ever validly
return the value 12345, so if one of the outputs is still 12345 we call
the macro again.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message