Greetings, all.  I do not know whether this is a misbehaviour, so I shall post
about it here rather than in the bugs group.

The following line fails to parse, with "All #declares of [etc] require
semi-colon ';' at end if the language version is set to 3.5 or higher".

  #local A = #if (1) 123 #end ;

If you shift the semicolon to before the #end, it's good.  Or, this:

  #local A = #if (1) 123+ #end 0 ;

The example here is trivial of course but in my case the "123" was actually a
vector coming out of the mother of all macros, so finding the root cause took
some head-scratching.

I can see why it happens:  POV is attempting to prevent the parser from diving
into the rabbit hole when the semicolon truly is missing.

(I just noticed that the error message could use a polish-up too, depending on
how fussy you are about English.)

Maybe it will help others who find themselves in the same jam.

Post a reply to this message

hi,

On 07/10/2017 10:04, Ard wrote:
> Greetings, all.  I do not know whether this is a misbehaviour, so I shall post
> about it here rather than in the bugs group.
> The following line fails to parse, with "All #declares of [etc] require
> semi-colon ';' at end if the language version is set to 3.5 or higher".
>   #local A = #if (1) 123 #end ;
> If you shift the semicolon to before the #end, it's good.  Or, this:
>   #local A = #if (1) 123+ #end 0 ;
> The example here is trivial of course but in my case the "123" was actually a
> vector coming out of the mother of all macros, so finding the root cause took
> some head-scratching.

parentheses help:

#local A = (#if (1) 123 #end) ;

regards, jr.

Post a reply to this message

jr <cre### [at] gmailcom> wrote:

> parentheses help:
>
> #local A = (#if (1) 123 #end) ;

Uh, I feel silly for not trying that.  Thanks JR.

Post a reply to this message

"Ard" <and### [at] gmailcom> wrote:
>
> The following line fails to parse, with "All #declares of [etc] require
> semi-colon ';' at end if the language version is set to 3.5 or higher".
>
>   #local A = #if (1) 123 #end ;
>
> If you shift the semicolon to before the #end, it's good.

That would seem to make sense (at least to me) for the following reason: If the
#if is 'true', then 123 is the value-- and a regular #local or #declare has the
semicolon after that VALUE itself.  Still, your example is an interesting one--
I've never used an #if() block *as* an Rvalue. (Hmm, what happens to #local A if
the #if is 'false'?)

I'm curious: In this successful example (shifting the semicolon), did you try
leaving out the #end statement altogether? If so, did the #local still work OK,
or did all hell break loose? ;-)

Post a reply to this message

Am 11.10.2017 um 12:26 schrieb Kenneth:
> "Ard" <and### [at] gmailcom> wrote:
>>
>> The following line fails to parse, with "All #declares of [etc] require
>> semi-colon ';' at end if the language version is set to 3.5 or higher".
>>
>>   #local A = #if (1) 123 #end ;
>>
>> If you shift the semicolon to before the #end, it's good.
> 
> That would seem to make sense (at least to me) for the following reason: If the
> #if is 'true', then 123 is the value-- and a regular #local or #declare has the
> semicolon after that VALUE itself.  Still, your example is an interesting one--
> I've never used an #if() block *as* an Rvalue. (Hmm, what happens to #local A if
> the #if is 'false'?)
> 
> I'm curious: In this successful example (shifting the semicolon), did you try
> leaving out the #end statement altogether? If so, did the #local still work OK,
> or did all hell break loose? ;-)

Please don't try this at home; a containment lab would be recommended
for such experiments ;)

As a matter of fact, there are known situations where leaving out
closing stuff (`#end`, closing parentheses, closing braces) in an
include file may indeed cause POV-Ray to crash hard.

And no, I'm not doing anything about it, because for each of these cases
I fix, I tend to discover two more that are twice as difficult to get
rid of.

It's a hydra thing, and I've decided to stop exhausting myself fighting
it. As long as it just lies there dormant, only swallowing the
occasional unwary passer-by once a year, I'm fine ;)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> Still, your example is an interesting one--
> I've never used an #if() block *as* an Rvalue. (Hmm, what happens to #local A if
> the #if is 'false'?)

Indeed.  There are lots of interesting things one can do within SDL that I would
have never thought to attempt - instinctually dismissing them as invalid.  I'm
sure there are some I haven't seen and no one's tried yet.

I just came across this neat little trick using conditionals that has the same
"I didn't know you could write things that way!" flavor:

http://www.econym.demon.co.uk/isotut/splines.htm
(at bottom of page)

"This is achieved by mutiplying one x spline function by (v<=pi) and the other
by (v>pi). The comparison operators return 0 for false and 1 for true, so the
sum switches from being one spline to the other when v becomes pi.

Similarly the z spline functions are multiplied by (cos(v)<=0) and (cos(v)>0),
which switch when v=pi/2 and switch back when v=3*pi/2."

Just thought I'd share while it was on my mind.
I need to try it with something like (cos(v)>=pi/2) | (cos(v)<pi)
to see if I can only invoke a certain range.
I was trying to noodle it out using select - but that seemed quite hard to
figure out how to specify a range.


Ooooh - unless I use the conditional as the first parameter....   <lightbulb>

Post a reply to this message

"Ard" <and### [at] gmailcom> wrote:

>   #local A = #if (1) 123 #end ;
>
> If you shift the semicolon to before the #end, it's good.  Or, this:
>

Geez, now I know why this looked familiar: it's because I usually write such
code on separate lines. Like so...

#local A =
#if (1)
123;
#else
0;
#end

The semicolon placements 'look' correct this way. I've done similar stuff in the
past.

Or, for the #else, if not zero, then maybe...

#else Let_POVRay_Decide // thus instructing the program to pick something that
it likes, of its own free will. Uh, it does *have* a built-in 'free will'
function, right?????????   ;-)

Post a reply to this message