On 4/6/22 10:44, jr wrote:
> my bad, the above was using alpha.9945627.  tried 'beta.1' and 'beta.2', both
> same as the alpha, all on a Slackware GNU/Linux box.  interestingly, WFP's
> 'povr' sees same/similar error as yours, but on a different line.  </grin>
> 
> File 'mopfont.inc' line 578:
> Parse Warning:
> Should have at least 2 objects in csg.
> File 'mopfont.inc' line 577:
> Possible Parse Error:
> Unmatched {
> File 'mopfont.inc' line 578:
> Parse Error:
> No matching }, ; found instead

The issue is the newer versions of the parser see the second of two 
semicolons - ';;' - as meaningful.

This partly due parser optimizations / changes. It's also a good idea 
for ';;' to cause parse errors as the extra semicolons - from macros 
especially - can cause difficult to understand behavior where unluckily 
positioned in the SDL.

---
The definition of the ComputeCornerLength macro ends with:

abs (L0 * cos (radians (MiddleAngle)));

It should be something like:

(abs (L0 * cos (radians (MiddleAngle))))

given it's calculating a return value.

Bill P.


Aside: My current povr issues warnings for the bounded_by usage in the 
include file. This user bounding is likely getting stripped given +UR 
now long the default. My v3.7 and v3.8 official versions issue no 
warnings at all(a). I don't remember making any changes specifically to 
get the warnings - FWIW.

(a) - Despite claims all user bounding is getting stripped by default, 
there are a few obscure exceptions in the official versions of POV-Ray 
where user bounds are respected no matter the +ur/-ur settings. The povr 
fork changed the code so +ur/-ur always strips the user bounding, or 
not, on the +ur/-ur setting. It might be the difference in warnings here 
is due bounded_by usage that happens to be one of the v3.7/v3.8, 
official release, 'hidden / always use a user's bounded_by' exceptions. 
I didn't investigate.

Post a reply to this message