|
 |
On 2/9/23 05:02, Kenneth wrote:
> Just discovered that your full original code example (WITH #debug) works OK, if
> the #local inside the macro is changed to #declare. Why that should matter, I
> don't know.
>
> #macro make_spline()
> #declare _s = spline {
> quadratic_spline
> 0, <0, 0, 0>,
> 1, <0, 0, 1>,
> 2, <1, 0, 2>,
> 3, <2, 1, 3>
> }
> _s
> #end
>
> #local myspline = spline { make_spline() }
>
> #debug concat("_pt=<", vstr(3, myspline(0), ",", 0, 3), ">\n")
>
The debugging you all have done has been helpful to me. Thanks!
Short on time but, I think we are seeing two different failure
mechanisms, the second being tangled in the fix for Ingo's spline issue
from July 2021. Ref:
http://news.povray.org/povray.beta-test/thread/%3CXnsAD687938A665Aseed7%40news.povray.org%3E/
Message: <XnsAD687938A665Aseed7@news.povray.org>
Running my povr branch with the final form of the fix using a clone
method suggested by Christoph over my original code, I get the
segmentation fault seen by many of you in newer official POV-Ray code. I
have traced the segfault to this bit in parser_expressions.cpp:
if (!New)
{
if (Old)
{
// Note. v3.7/v3.8 was always: New = new LinearSpline(*Old);
New = Old->Clone(); // <-- Segfault with Clone method.
If I revert to the previous & incorrect code of:
New = new LinearSpline(*Old);
I then see:
Parse Error:
std::bad_array_new_length
which is perhaps a different signature for the same bug, but I've not
had time to dig into it.
Also not looked yet at the v3.7 stable code. The parser changed somewhat
significantly after v3.7 as many know.
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.
Bill P.
Post a reply to this message
|
 |