"Bald Eagle" <cre### [at] netscapenet> wrote:
> I've run into the issue where assigning the final value(s) of a macro to an
> indentifier such as "Result" and then having the final line of the macro be:
> Result triggers the ole' "attempt to assign uninitialized identifier to Lvalue"
> error.
> I'm hoping that this might help WFP fix this in the yuqk fork, identify where
> things went off the rails between earlier versions and 3.7/3.8, and propose a
> robust fix for this long-standing and really annoying bug that can nearly drive
> one insane.
>
This 'bug' doesn't bother me. Perhaps I' already insane ;) When learning POV
someone said that the macros are not true C or C++ macros. So I just learn to
accept what works and what doesn't. If you 'fix' doesn't cause more problems, I
see no harm.

Have Fun!

Post a reply to this message

"Leroy" <whe### [at] gmailcom> wrote:

> This 'bug' doesn't bother me. Perhaps I' already insane ;) When learning POV
> someone said that the macros are not true C or C++ macros. So I just learn to
> accept what works and what doesn't. If you 'fix' doesn't cause more problems, I
> see no harm.
>
> Have Fun!

Well the issue is that sometimes it shows up and sometimes it doesn't.
And that has caused issues where previously working scenes suddenly didn't work
anymore.
And the intermittent appearance makes debugging a nightmare.

Providing a "minimal scene that reproduces the error" is either impossible, or
the bug doesn't show up when run on someone else's system.

Also, writing:

#macro (Argument)
....
a bunch of povray code
....
#local Result = (my final calculation)

Result

#end

just gives a clean, easily followed logic, since you know that the macro emits
"Result" when exiting.

It used to work just fine, or at least very very often, and then something got
changed and it's a 50/50 shot whether or not the parser wants to let it work or
not - which is not something that I want to be fussing with when trying to write
1000 lines of complicated SDL.

So a solid, reliable fix would be well worth it if the source code edit is
fairly simple.

- BE

Post a reply to this message

Hi Bill

Some posts in this old thread, started March 28th 2000 by Sigmund Kyrre Aas, may
also be relevant:

Newsgroup: povray.advanced-users
Subject: Re: Macros acting strange

https://news.povray.org/povray.advanced-users/thread/%3C38E10B3A.7C6D3308%40stud.ntnu.no%3E/?mtop=61708&moff=4

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

Hi Tor!

I've been bus reviewing all sorts of code, and that of course led me across all
the different places that we've crossed paths.
So I was literally just thinking about you for the past few days.

I'm sure you're super busy as always, but hope that you get enough down-time to
enjoy things.

Thanks for that 26-year-old post. (!)

What other dark secrets lay dormant in the POV-Ray parser, waiting to one day be
awakened . . . ?

- BE

Post a reply to this message

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> Hi Bill
>
> Some posts in this old thread, ... may
> also be relevant:


This one too:

https://news.povray.org/povray.general/thread/%3Cweb.63cc2badcc2a7a8c1742c61c57ffd389%40news.povray.org%3E/?ttop=446984
&toff=200

Post a reply to this message

Which is the same macro construct as the following:

// ------------------ Scalar failure ---------------------------
#macro BugScalar(A,B,X)
    #if (X < A)
        0
    #else
        ((X - A) / (B - A))
    #end
#end



// ------------------ Vector failure ---------------------------
#macro BugVector(X)
    #if (X < 0.5)
        <1,0,0>
    #else
        <0,1,0>
    #end
#end



However this works:
#macro Test (N)
 0
#end
#local Val = Test (1);

and (provisionally)

#macro Test (N)
    #if (N < 1)
        #local Result = 0;
    #else
        #local Result = 1;
    #end
    Result
#end

#local Val = Test (1);

Also, as Mr. Callwood advised in an older thread,
wrapping the internals of the macro in parentheses allows successful evaluation:

#macro BugScalar(A,B,X)
(
    #if (X < A)
        0
    #else
        ((X - A) / (B - A))
    #end
)
#end

Post a reply to this message

Now, jr has mentioned various thing about my semicolon usage.
I noticed upon review that I can successfully assign an array without a
semicolon, and then it's only the subsequent array that triggers the error when
it doesn't have a semicolon.

So I'm thinking that it might be partially about the semicolon, but also that
the parser allows "tandem assignments" through without raising any kind of
warning or error.

See:

https://news.povray.org/web.68fc36a5251da1bc1f9dae3025979125%40news.povray.org

I noticed that the parser allowed and didn't complain about:

#local in2 = #local Result = {EcResult [2], EcResult [4]};

So who know what other wacky constructs it will let slip through.

- BE

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Now, jr has mentioned various thing about my semicolon usage.
> I noticed upon review that I can successfully assign an array without a
> semicolon, and then it's only the subsequent array that triggers the error when
> it doesn't have a semicolon.

_can_ because the parser is "forgiving", but relying on .. a quirk ?

"Note: There should be a semi-colon after the expression in all float,vector and
color identifier declarations."
<wiki.povray.org/content/Reference:Declare_and_Local_Directives#Declaring_identifiers>


> ...
> I noticed that the parser allowed and didn't complain about:
> #local in2 = #local Result = {EcResult [2], EcResult [4]};
> So who know what other wacky constructs it will let slip through.

not that one[*], beta.2 says:

Parse Error: Expected 'RValue to declare', { found instead

same with parentheses (tried supplying a "tuple" instead).

[*] replaced the 'EcResult's with '123.456' and '789.012'.


regards, jr.

Post a reply to this message

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

> > I noticed that the parser allowed and didn't complain about:
> > #local in2 = #local Result = {EcResult [2], EcResult [4]};
> > So who know what other wacky constructs it will let slip through.
>
> not that one[*], beta.2 says:
>
> Parse Error: Expected 'RValue to declare', { found instead
>
> same with parentheses (tried supplying a "tuple" instead).
>
> [*] replaced the 'EcResult's with '123.456' and '789.012'.

On 3.7 or 3.8?
Because remember, clipka was playing around with a LOT of parser stuff during
that time, adding and then rolling back. IIRC, that's when I started noticing it
more.

Also, thanks for running the test(s).

- BE

Post a reply to this message

https://news.povray.org/6613cd42%241%40news.povray.org

"There are issues in all the recent parser variations with respect to
sometimes necessary, but missing semicolons. The yuqk fork has addressed
a few of them in its version of the parser, but certainly not all.

The worst cause flaky behavior during parsing without any notice
something has gone wrong."

Post a reply to this message