On 2/9/23 07:39, William F Pokorny wrote:
> What I suspect off the top of my head is more recent parser code is 
> dumping the macro defined #local spline where it should not. The first 
> question is why and have a thought or two(a).
> 
> (a) For example, wondering about the new macro caching mechanism and 
> whether it makes the macro 'look' like it's in another ram file with 
> respect to #local ID / spline content persistence.

True to form, my first guesses as to the problem were mostly wrong. :-)

The v3.7 code was aware the #local spine ID might go out of macro or 
file scope. The code did extra work using the old style C++ object 
reference counting and, if need be, local copies of the spline. This why 
v3.7 works for the originally posted code.

At some point after v3.7 the the Parse_Spline() code was substantially 
re-written for reasons about which I'm unsure(a), but in part it 
eliminated the reference counting bits which protected against premature 
deletions of objects by the parser on scope changes.

The code appeared to me to have other issues too. I've attached an 
updated Parse_Spline() which in v3.8/v4.0 is found in:

source/parser/parser_expressions.cpp

The updated code works for all my povr branch spline testing. It will 
likely fix any v3.8/v4.0 code too, but I've not tested that claim.

Bill P.


(a) The newer code allows some interesting things like:

#declare A1=spline {
    cubic_spline
    -0.5, < 1,-1, 0>
     0.0, < 1, 0, 0>
     0.5, < 2, 1, 0>
     1.0, < 1, 2, 0>
     1.5, < 1, 3, 0>
}
#declare A2=spline {A1 linear_spline}
#declare A3=spline {A1 natural_spline
         2.0, < 1, 4, 0>
         2.5, < 2, 4, 0>
         3.0, < 2, 2, 0>
}

Post a reply to this message

Attachments:
Download 'parse_spline_update.cpp.txt' (4 KB)