There is a bug specific tuple (batch) ID assignments from vectors.

The detail for which is again being eaten by the spam filter.

Bill P.

Post a reply to this message

On 11/4/23 03:04, William F Pokorny wrote:
> There is a bug specific tuple (batch) ID assignments from vectors.
> 
> The detail for which is again being eaten by the spam filter.
> 
> Bill P.

Attempting to attach original post as text file.

Post a reply to this message

Attachments:
Download 'tuplevectorassignmentbug.txt' (2 KB)

On 11/4/23 03:07, William F Pokorny wrote:
> Attempting to attach original post as text file.

Attempting again to post about issue again with Chris's spam filter fix 
in place.

  I've been working through more tuple (batch) ID assignment test cases. 
In the documentation I've been able to turn up for the original tuple 
capability, there was this bit related to assigning components of 
vectors to individual identifiers:

---
In addition, a similar syntax extension has been added for easier 
assignment of vector components to individual variables:

     #declare < ID1, ID2, ... > = VECTOR_EXPR;

This statement is fully equivalent to:

     #local TEMP = VECTOR_EXPR;
     #declare ID1 = TEMP.x;
     #declare IDY = TEMP.y;
    ...

except that the new syntax does not actually define a local variable 
named TEMP.  The terminating semicolon is mandatory.
---

All seems to work except the mandatory semicolon bit is not enforced by 
the parser!

This means the following code runs without complaint, but incorrectly.

     #declare <A0,A1,A2> = <3,2,1>; // This works.
     #declare <A0,A1,A2> = <1,2,3>  // This only appears to work
                                    // Meaning no parse error
     #debug concat("A0 = ",str(A0,3,1),"\n")
     #debug concat("A1 = ",str(A1,3,1),"\n")
     #debug concat("A2 = ",str(A2,3,1),"\n")

     #error "Stopping at parse test end\n"

The exposure made worse because in other applications, the tuple ID 
assignments treat the trailing semicolon as optional.

Bill P.

Post a reply to this message

On 11/6/23 10:04, William F Pokorny wrote:
> All seems to work except the mandatory semicolon bit is not enforced by 
> the parser!
> 
> This means the following code runs without complaint, but incorrectly.
> 
>      #declare <A0,A1,A2> = <3,2,1>; // This works.
>      #declare <A0,A1,A2> = <1,2,3>  // This only appears to work
>                                     // Meaning no
parse error
>      #debug concat("A0 = ",str(A0,3,1),"\n")
>      #debug concat("A1 = ",str(A1,3,1),"\n")
>      #debug concat("A2 = ",str(A2,3,1),"\n")
> 
>      #error "Stopping at parse test end\n"
> 
> The exposure made worse because in other applications, the tuple ID 
> assignments treat the trailing semicolon as optional.

An update. It was apparent once I dug through the code that clipka 
intended for the vector form to work like other tuple assignments in not 
needing a trailing semicolon, but allowing one.

The vector tuple form is broken in all parsers since mid 2015 in not 
working as intended or failing for lack of semicolons.

Try as I might over the past few days, I've not been able to make it 
work as intended without breaking the general ability to declare things 
nearly anywhere.

A capability which looks to be the primary reason we sometimes need 
semicolons. We need to somehow mark the end of all the '#' language 
directives where we allow them in the middle of a other parsing.

It's also very much related to how grabbing a single token can sometimes 
cause the parser to eat up a bunch of scene code and do nothing with it. 
This last is exactly what is happening in the sample code up top. It is 
what was happening with this recent bug find too:

https://news.povray.org/povray.beta-test/thread/%3C6533cdad%241%40news.povray.org%3E/

I've take a run or two at forcing the semicolon in this one tuple / 
batch assignment type, but so far I'm failing there too. That said, I 
think this the more likely outcome at the moment.

Bill P.

Post a reply to this message

On 11/6/23 11:29, William F Pokorny wrote:
> I've take a run or two at forcing the semicolon in this one tuple / 
> batch assignment type, but so far I'm failing there too. That said, I 
> think this the more likely outcome at the moment.

I believe this fixed in the yuqk fork - in that lack of a semicolon is 
now flagged as an error. Only took a week... :-(

Bill P.


Details for those interested.
-----------------------------

Added an optional parameter in hereViaRValue defaulted false to:

Parse_Unknown_Vector()

called from Parser::Parse_RValue() and set true. Plus to

Parse_Express(expr, &terms, true)

called from Parser::Parse_Declare() and set true.

Plus to a set of expression related functions and calls in 
parser_expressions.cpp so the proper indication of the 'right value 
parsing' state exists in the function called Parser::Parse_Num_Factor() 
where the vector dot access parsing happens near the bottom.

It appears when the dot access methods were coded, the right side 
parsing state was never extended down into Parse_Num_Factor(). Further, 
necessary checking for semicolons was never created. Such checking needs 
to know whether the parser was in a right hand value parsing state.

This despite code being used where the dot access bit sometimes, 
necessarily, is triggering the execution of directives coded right in 
the middle of other work parsing work(a).

(a) - The triggering by way of a side effect of somewhere down the call 
chains grabbing directive tokens while the parser is in a state which 
allows the mid stream directives.

What all this means.

In the yuqk fork, the vector form of tuple / batch / list ID assignments 
should work. Further, due the additional checking down in the dot access 
methods for semicolons, it should be much less likely other non-tuple 
form vector type assignments can cause unwanted side effects due the 
lack of a semicolon. It would have been complicated SDL code which fell 
into the trap previously. If users previously tripped it, and got 
confusing results, my bet is they probably simplified their code - and 
things began to work.

I offer no equivalent v3.8 parser fixes beyond what can be found in my 
code or the description herein. Partly, this because I leaned on some 
newer yuqk / v4.0 parser functionality for the fix but, the update is 
complicated and I'm not going to try and replicate it in another version 
of parser code.

Disclaimer. There are simply too many paths into Parse_Num_Factor() for 
me to be 100% sure all situations which could be a problem are fixed. My 
test cases are clean... It's better than it was.

Post a reply to this message