|
 |
I recently came across a subtle problem with semi-colon placement, when used in
*particular* v3.8 development versions (in Windows). It took me some time to
track down, and to figure out a simple test to reproduce it:
---------------
#version 3.8;
global_settings{assumed_gamma 1.0}
#declare VEC = <.3,.5,.7>;
#macro MY_MACRO(FOO)
#local BAR = FOO;
<BAR.x,BAR.y,BAR.z>;
#end
#declare XYZ_POS = MY_MACRO(VEC);
---------------
In versions 9811560+av591 and 9893777+av622, the above code works without a
problem. But in later versions 10013324+av645, 10064268+av691, and
10064738+av694 , the semi-colon after
<BAR.x,BAR.y,BAR.z>;
causes a fatal error.
A macro is the only structure to be sensitive to this, that I have discovered so
far-- perhaps because it's one of the few code structures that, depending on
use, does not specifically need a semi-colon after its 'result'.
Maybe the later development versions 'tightened up' the rules of semi-colon use
in general?
In any case, there are two ways to fix this in the later versions:
1) Put a semi-colon after <BAR.x,BAR.y,BAR.z> but NOT after
#declare XYZ_POS = MY_MACRO(VEC)
2) REVERSE that order
In the earlier versions, semi-colons can be used in both places at once-- or
like 1) or 2) as well. (I haven't yet tried any v3.7xx to see what happens
there.)
Just something to be aware of for the future.
Post a reply to this message
|
|
|
|
On 10/28/20 12:40 AM, Kenneth wrote:
> I recently came across a subtle problem with semi-colon placement, when used in
> *particular* v3.8 development versions (in Windows). It took me some time to
> track down, and to figure out a simple test to reproduce it:
> ---------------
> #version 3.8;
> global_settings{assumed_gamma 1.0}
>
> #declare VEC = <.3,.5,.7>;
>
> #macro MY_MACRO(FOO)
> #local BAR = FOO;
> <BAR.x,BAR.y,BAR.z>;
> #end
>
> #declare XYZ_POS = MY_MACRO(VEC);
> ---------------
...
>
> Maybe the later development versions 'tightened up' the rules of semi-colon use
> in general?
>
My guess is double semicolons are no longer allowed after Christoph's
parser performance changes in v3.8.
One thing done was to implement a fast scan ahead which looks for the
end of if blocks for example so they can be digested / skipped in
chunks. Here I think it scans ahead for the required trailing ; finding
the last one, but what is just prior isn't what's expected, but rather a
semicolon preceding the last found.
I suspect your test case could be just
#declare VEC = <.3,.5,.7>;;
Bill P.
Post a reply to this message
|
|
